From: William_J_G Overington (wjgo_10009@btinternet.com)
Date: Mon Jun 07 2010 - 02:01:38 CDT
On Sunday 6 June 2010, Robert Abel <freakrob@googlemail.com> wrote:
> On 2010/06/05 15:38, William_J_G Overington wrote:
>> I feel that the encoding of a portable interpretable object code into Unicode could be an infrastructural step forward towards great possibilities for the future.
> And yet you have not managed to list a single merit of your portable, interpretable object code. Neither in the draft spec, which really didn't explain anything about what was proposed, nor on this mailing list. The possibility for viruses was mentioned, too.
Indeed it was.
However, no evidence whatsoever has been produced that there is any virus threat from the system at all. There is no facility for outputting characters and the code is interpreted not compiled. Now, I do not know enough about viruses to say that there is no virus threat and, as a researcher, I try to be precise about evidence and analyse it carefully to the best of my abilities. Certainly I would like there to be no virus threat from the system, but that is not the same as having evidence that there is no virus threat. However, I add that I feel that it would be unfair for the whole system to be regarded as a virus threat just because the word virus has been used by someone.
> Personally I don't see the merits of your idea. You can exchange ASM-style code in a text file or binary file and interpret that within your application if you like.
The portable interpretable object code has the advantage that text and software are in the same input stream, in plain-text format, easily separable one from the other yet presented so that the relative positions in the sequence of each text item and each software item is precisely clear.
> Especially you said at one point it was going to solve globalization issues:
>
> On 2010/06/02 11:51, William_J_G Overington wrote:
> > The portable interpretable object code is intended to be a system to use to program software packages to solve problems of software globalization, particularly in relation to systems that use software to process text.
Well, I did not quite say that it was going to solve globalization issues: it would be a system that people could use to program software packages to solve problems of software globalization.
> I actually looked into your draft.
Thank you for studying the document.
> It pretty much encodes some assembler commands and some basic commands for program flow. It doesn't really offer any insights into this either.
Well, the idea is to produce portability. The whole purpose is portability by means of standardization within the framework of Unicode and mixing text and software in the same information stream in plain-text format.
> You can draw images and text in most applications just fine, even specifying font and color. Besides the proposed putpixel method being very slow, there seems no additional merit to portable, interpretable object code. Indeed, it seems to create much overhead in any application that would incorporate it.
Well, putpixel is just to be able to make a start. Hopefully other constructs could be added, yet there are issues of making them portable, of making them fair (such as between the various vendors of fonts) and that adding more constructs increases the size of the interpreting module within the whole application that is processing the incoming text stream. I remember that when teletext was introduced in the mid-1970s in the United Kingdom, one form of character coding was chosen rather than another because the chosen coding would need 1 kilobyte of memory and the other coding would need 2 kilobytes of memory and the cost of that difference in memory was substantial at that time. Times have changed and the cost of memory has decreased greatly. So, in regard to increasing the choice of output functions built-in to the encoding and thus increasing the complexity needed in the interpreting program, there is a balance to be decided upon. I have started with
putpixel and hopefully the encoding process can add more commands as a consensus opinion is hopefully formed.
The overhead is the price of portability. The main advantage of the portable interpretable object code is that it is portable.
> The whole issue with viruses and sandboxing seems problematic at best.
Well, is there an issue with viruses and sandboxing? The word virus was mentioned: no evidence that the system poses a threat in relation to viruses has been presented. The sandboxing has been done with care. I would like the issue of virus threat or otherwise to be resolved by people who know much more about viruses and sandboxing than I do. Spoiling the whole opportunity just because the word virus has been mentioned is very unfair.
In the http://www.unicode.org/mail-arch/unicode-ml/y2010-m05/0056.html post, I wrote as follows.
quote
I am hoping to submit a document to the Unicode Technical Committee in the hope that the Unicode Technical Committee will institute a public review.
end quote
That is my present goal. I feel that if such a Public Review were to be instituted by the Unicode Technical Committee, then many experts would study the ideas and comment about them. Maybe some people who know about programming the iPad would try to implement an interpreter using codes within the Private Use Area using F for X and A for Y in relation to the codepoints mentioned in the draft document.
William Overington
7 June 2010
This archive was generated by hypermail 2.1.5 : Mon Jun 07 2010 - 02:08:25 CDT