Re: [MiNT] mint web/apache idea

["Stanislav Opichal" <opichals@espace.cz>]

Hi!

> > ago as a product of our summer workshop. I'll ask the alpha's root to
> > establish the
> > alias "FAB". I'll send a note if I'm successfull.
>
> Fine.  But we're still looking for a coordinator ...

I think Mario will be able to respond faster. I've contacted root, but I've
had
some mail problems that time... After Mario's offer I didn't continue in
the endeavour just because Mario is cappable to ensure more than a
mailinglist.

BTW: I think it would be good to establish th elist just now to not to
bother
in MiNT with these mails

> The libwww depends mostly on a properly implemented select() system
> call.  The default "event loop" is simply a select() on all open
> descriptors (including stdin for user interaction).  Activity on one of
> these descriptors is an "event".  That is only the default used e. g. for
> the line mode browser.
>
> A more sophisticated browser than the line mode browser will replace this
> event loop with its own version, however, the libwww is still based on
> select().  At some point you will poll the open descriptors
> (i. e. sockets) for activity and then pull/push the data.  This is
> essential.
>
> > > machine without real threading.  The VM has to provide internal
threading
> > > functionality anyway.
> >
> > VM? Do you mean JavaVM? Sure Java should be "multithreaded" in any way
> > to let the whole thing work.
>
> Yep, (Java) virtual machine.
>
> > > > MagiC?
> > > >     solution: port the libwww to use it with MagiC and everything
should
> > > > work then.
> > >
> > > Right.  If all networking is encapsulated within the libwww there
would be
> > > no problem.  But if I worked for ASH I would prefer to port the
libsocket
> >
> > Isn't it? I mean "Is the whole networking in libwww" ?
>
> The libsocket consists of a handful of low-level network functions, like
> connect, accept, listen, ...  It's really not more than a handful and it
> is relatively simple to port.  The rest of the libwww (or any other
> networking software) will then compile and run out of the box.
>
> If you port libwww you will have to revise thousands of lines of code and
> add a lot of "#ifdef YET_ANOTHER_TCPIP_STACK".  Nobody will do that
> because it is too much work and it is not very likely that the w3c will
> ever make that patch part of the official distribution.
>
> > > > Other thing is the rendering machine... It should be highly module
> > > > divideable (possibly .SLB as the standard PlugIn interface)
architecture
> > to
> > >
> > > I probably don't have to repeat here that I'm not very fond of the SLB
> > > interface.  There are some practical reasons that make it IMHO unwise
to
> > > use for the browser.  First, I think that the code base for a web
browser
> > > will be so large that most people will prefer to cross-build it on a
> > > faster platform.  I doubt that there will be a cross-linker that can
> >
> > What platform for example? I think this would be SO OS dependent part
>
> It is not os dependent at all.  Cross-compiling means that you only create

I was thinking about the rendering machine itself... the presentation level
would
be definitely OS dependent. I see your minds now clearly, sure the point is
to
keep it whole GNU compatible.

> > I can't see the point, GNU is not capable to create an SLB? Explain this
in
> > more details, please. (probably my English is not good enough... sorry)
>
> The GNU linker can only create GEMDOS programs, not SLBs.

Oh, I didn't know this.... This fact explains the problem here.

> > > software companies that are already active in the Atari sector to
write
> > > plug-ins for the browser if they knew that they could reuse their code
for
> > > Microscape plug-ins and maybe turn their efforts into a commercial
> > > success in the world beyond the Atari.
> >
> > Do you mean that our FAB plug-ins should be "interface compatible" with
> > any other interface definition used in other WWW Browser? Is it worth
it?
> > Would anyone really port a plug-in from MSIE to FAB?
>
> Why not?  The other way round may also be interesting.  You can port FAB
> plug-ins to Microscape (BTW, MSIE has mostly the same API as Netscape
> which is no surprise).  Of course FAB plug-ins could only be
> source-compatible to MSIE/Netscape plug-ins.

OK, I didn't look at the sources. Certainly it would be nice to port some
plug-ins,
but there is a matter of efficiency of the port (the code itself). Atari
optimised
program is much faster than any of the port (if you exclude the possibility
to
rewrite the code... just looking in the original one... but his is not a
port, is it? ;-) )

Stan