Witold Filipczyk wrote:
>>3) Let's talk about open source Arachne instead.... and how to force OEM
>>customers to subsidize Arachne development anyway... ;-)
>
>
> Let's talk about it.
> I have some concepts and ideas how should it (browser) be done, but I'm still
> not enough enthusiastic to do it by myself.
> It should be layered, modularized, with use of Unix principle of "Makefiles"
> and "pipes".
Exactly.
> INPUT --> parser --> JS-like structures --> internal_structures --> rendering
> of data
>
> any change before "-->" regenerates structures after "-->"
> The goal is to do it in similar way like Makefiles:
> after change on the left side, only necessary part on right side
> is regenerated.
Hmm, this would be cool. For example, first thing new Arachne has to do
is to re-render (and on 16+ bit display, even re-display) only those
frames, which have changed. This would allow multi frame mail reader,
which was possible in current Arachne, but it was impossible slow to use
(so I haven't released it). Sometimes, multiframe layout would make
sense, although most of all, I like two-frame view (Norton/Midnight
commander style; it makes sense even for mail reader...)
> INPUT could be been not only network, but eg. keyboard.
> Arachne in addition to "browser" could be WYSIWYG HTML editor, or even
> word processor (Keyboard is much slower than network).
Hmm, this is too complicated, and additionaly, anyone can launch Mozilla
for that, it is done already in high quality. And in StarOffice, you can
even copy+paste HTML table from HTML page to DOC page (generic text
editor window...).
I want Arachne to stay lightweight. Norton/Midhnight commander-type
application. HTML viewing and e-mail are both basic tasks of current
PCs. WYSIWYG HTML editing not...
> OUTPUT -> graphic screen, text terminal, Postscript
This is already done in such modular way....
> Structures of data should be universal to many uses.
> Such "-->" could be much more than on diagram, but all converters "-->" should
> be simple as possible.
>
> Events from User should be treated in similar way.
Well, this is not done this way. Only common user even api is URL input
field. It would be nice to be able to redefine hotkeys - maybe all API
should be JavaScript, and user can define own menu and hotkey map using
mapping to JavaScript commands (I don't like JS, but we must implement
it, and why implementing more than one API ?)
> First step is to:
> - define structures "after parser" and "before render"
This more or less exist in current Arachne.
But I am rather talking about defining lower level API - for portable
JavaScript library. Let's implement about 20-30 basic I/O and graphical
commands, which will be available on all supported platforms....
I was thinking about:
int f=aopen("URL","r|w")
aready(f) ................. checks, whether data are available
aeof(f) .... check for end of file/connection closed
aread(f,buf,size)
awrite(f,buf,size)
agets(f,buf,maxsize)
aputs(f,buf,maxsize)
aclose(f)
(and of course aselect() and await() as simplier-syntax alternativ for
POSIX select() command, but this is only for advanced users, and
probably irrelevant in DOS ;-)
So we can do eg.:
aopen("file:\c:\autoexec.bat","r");
aopen("file:/etc/inittab","r");
aopen("http://arachne.cz/","r";);
aopen("pop3:[EMAIL PROTECTED]","r");
etc., etc. Simply network transparent, platfrom independent file open.
Cache would be maintained on lower level. This is what eg. Mozilla does
(and sometimes not very good!).
The "r" and "w" flags are from generic fopen() command, but we can add
"c", which means reading from cache if available, why "r" would
"reopen/reload" object.
I would especially like if this API can do eg.:
aopen("file:somefile.zip/file_id.diz");
(file_id.diz files are now obsolete, but it is just an example ;-)
So mime.cfg conversion stuff would be also hidden under this layer...
and I would like to extend it by virtual filesystem stuff,
I think that from such functionality in Flowerpot would benefit even
programmers outside Arachne project...
Other function calls should include:
acls()
aline()
abox()
adecoratedbox(); (so we can have themes like Gtk or XMMS... ;-)
adrawimage(filename);
amousex()
amousey()
amousekey()
akeypressed()
abioskey()
etc.
Simply - we need simple and strictly specified functions, which have to
be ported in order for Arachne to be portable. I want this API to be
clean, and consisting only from few basic functions, so it is easy and
fast to port. More complex functionality which doesn't required system
interaction can be hardcoded in Arachne - except of network transparency...
--
Michael "xChaos" Polak
+420 603 872631 / +420 2 33355668 / ICQ# 40434104
http://www.arachne.cz (Arachne Labs homepage)
http://www.mp3records.cz (100% legal and free music)
http://www.legalizace.cz (Stop drug war & release victims !)
http://www.vojna.cz (Petice za zruseni vojny i civilni sluzby)
