On Sunday 6 June 2010, Robert Abel <freak...@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
