Dne Thu, 4 May 2000 04:35:04 +0200, [EMAIL PROTECTED] (arachne-digest)
napsal:
> Hmm.... IMHO the categories are:
> 1. They don't know about JS (pre-JS browsers)
> 2. They know about JS
> a. JS on -> JS is interpreted
> b. JS off -> Ignores JS
> c. otherwise ignores JS
> And Arachne tries to fit into 2c. If the browser doesn't know about JS a
> script like this:
Yes, it it is "2c". I am treating it as "invisible tag", like <TITLE>
</TITLE> or <TEXTAREA> </TEXTAREA>. In fact, <SCRIPT> will be based on
<textarea> implementation, because the very basic interpretation is
the same: content must be hidden from web page, and stored in separate
object capable of holding multiline text files. With SCRIPT, this object
just won't be visible as text-editing box, this will be the only
difference. But I will be able to use Arachne's internal text file
manipulation functions to interpret the script code...
> <SCRIPT>
> document.writeln('Hello World!')
> </SCRIPT>
> Would put the text "document.writeln('Hello World!')" on the screen. I
> think Netscape made an error when they didn't make the tag like this:
> <SCRIPT
> document.writeln('Hello World!')
No, this wouldn't be very good. Some browsers would crash or be confused
on mulltiline tags... Arachne would handle this, but only for some
limited length of script.
JavaScript is non-systematic concept, IMHO. I would add special tags,
which would be ignored by old browsers, but which would have same
functionality like JavaScript. Unfortunately, authors of JS prefered
object oriented approach, as it was latest programming fashion some 5
years ago. Today, XML-like approach is more popular.
I would do commands like
<SCRIPT CMD="Print" ARG="Hello World">
or maybe rather
<SCRIPT CMD="Echo Hello world!">
So language would have command.com/bash/perl shell-like sytanx, with
non-obligatory string delimiters. I would make it part of HTML, rather
than creating separate pseudo-language. And no special object names
and "numbers" will be needed to learn: Some operations, like onmouuse
exchange of image, will be much easier:
<IMAGE SRC="1.gif" ONMOUSE="Set SRC=2.gif">
"Variable names" would be for each tag identical with TAG arguments,
and only special "entry points" to the code would be added to HTML.
Additionaly, parsing of script and parsing of HTML would be same process
so for example scripts like folliwng would be possible:
<SCRIPT CMD="if $USER_AGENT[0,6]==Arachne goto #Skipmessage">
<H1>You are NOT using Arachne WWW browser...</H1>
<A NAME="Skipmessage">
> Then any browser would be able to ignore JS succesfully without being
> rewritten. But at the time they were (more or less) the only browser
> company that existed so...
Netscape Communications needed hard to implement language. What I have
descibed would be easy to implement and easy to use - and Netscape
needed to stay ahead of competition.
> This is NOT true, it did take off and the reason was that Netscape was by
> far the biggest browser developer out there. (And you can do some quite
> nice looking effects with JS).
But they would be possible even with much easier language - both to learn
and implement :-(
.....
> But realistically, I think the Linux version is going to take all his
> energy and enthusiasm for at least the rest of the year - maybe more.
It has to be finished much sooner!
> And the bug fixes, when they come, will be for the LINUX version. <G>
> (They WILL be needed)
But there is still only one Arachne, and most of functionality is
shared between DOS and Linux build... if Linux version recognizes new
tag, DOS version will recognize it too.
> Any improvements that come about as a result of developing the Linux
> version will not migrate to the DOS version until Michael has a good
> reason to pause in the Linux advance.
>> Any improvements that come about as a result of developing the Linux
>> version will not migrate to the DOS version until Michael has a good
>> reason to pause in the Linux advance.
> Michael and I have made it so that the DOS and Linux versions build
> from exactly the same sources. Michael insisted very much on that
> point, as he is _not_ leaving DOS and his users for greener,
> unixish pastures. At the moment the linux port isn't complete but
> both versions compile from exactly the same set of sources; there is
> no forking, don't worry.
Emannuel, you are on this list ?! This is kind of industrial espionage!
;-)
> Getting Arachne to compile under Linux (an environment where most
> buffer overruns, etc. are trapped) is actually helping to find bugs that
> would be a lot harder to find in DOS (which doesn't care at all about
> overruns and all that). When leaks/overruns are found and fixed,
> they are therefore fixed in *both* versions. So the next DOS version
> will have some issues fixed, even if work was concentrated on
> the Linux port!
It is not that easy. I can't use either rhide or xwpe when debugging
SVGAlib version... well, I think that xwpe may actualy work, as
SVGAlib apps acquire new graphical console when launched from X11, so
it should work even with gdb. At the moment, my older installation
of xwpe from RH 5.1 doesn't work with RH 6.1 (library problem or
whatever), but I am in process of reinstalling xwpe.
I am sorry, but I am too lame to use traditional text-mode gdb tracing
of coredumps... it would help me a lot to have classical Borland-IDE
style of tracing directly in source code :(
What I would in fact need most of all, is INSTANT presence of all those
existing, well-known and tested-for-years DOS tools in Linux...
> The linux version will not require X-Window (it can display under X
> just fine, if requested, though); when Arachne-for-Linux is out, you
> can probably give it a try with some 'throwable' distribution like
> ZIPLinux, DOSLinux, and whatnot..
But installation of SVGAlib may be problem for Linux beginners...
> Well anyway, my point was that a unixish environment is a lot easier for
> finding memory-related issues (leaks, overruns..), and other bad
> things; such improvements will automatically benefit the DOS version..
Yes, it is easier to crash the entire application - but it is not easier
to trace the bug :-( Especially when porting huge existing application.
(I am currently having terrible problems with reading keyboard in
SVGAlib, BTW. SVGAlibs raw keyboard access is different from anything I
have ever used...)
....
> I'm putting a copy of this exchange into the time vault - I just want to
> have it available when Arachne 1.7 comes out. If placing bets that further
> Arachne development for DOS will be delayed by development for Linux helps
> to make Michael (or you) try to prove me wrong, then I'll place a new bet
> every day. <G>
I was thinking that first Linux version will be 1.63 alpha, and then
I won't move to 1.7 before all Arachne functionality is available in
Linux. Currently it will be just opposite than you expect: not 100% of
DOS functionality will be available in preliminary release of Arachne
for Linux...
--
Michael Polak: [EMAIL PROTECTED]
Arachne Labs: http://arachne.cz/
My mobile phone - up to 160 characters: [EMAIL PROTECTED]
