Re: [MiNT] mint web/apache idea

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

Hi,

I had to take a week off, sorry.

On Thu, May 18, 2000 at 12:32:55AM +0200, Stanislav Opichal wrote:
> Hi!
> 
> > Right.  But there is no such mailing-list and I have to keep on polluting
> > this one. ;-)
> 
> Well, I've been thinking about this for a while and I think I can create
> such a list
> at weblist@alpha.inf.upol.cz which is the listserver we've programmed a few
> years
> 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 ...

> > > OSes:
> > > MiNT + Threads
> > >     cause: already ported libwww from w3c, which would reduce the
> browser
> > > problem a lot.
> >
> > The libwww gets along with pseudo-threads (via select) and that's actually
> > sufficient for multiplexed i/o.  You could even embed a Java virtual
> 
> I know (of the very little I read about the libwww) that it provides
> pseudo-threads,
> but I don't know how this actually works and thus whether it can be used
> e.g.
> in MagiC to use its own threading.

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
the programs (compile, assemble and link) on another machine.  The
generated code will of course run on the Atari and it is even binary
identical to code generated on the Atari.  The code generation is only a
lot faster.

> that any port of that would cause rewritting of the whole thing (rendering
> machine). I meant SLB just to have unified interface definition made not by
> us but by others before us ;-) therefore no SLB is essential.
> 
> > create SLBs.  The GNU linker configured for the target m68k-atari-mint
> > will compile out of the box on almost every Unix system.
> 
> 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.

> > Second, SLBs need extra care in the code design which will inhibit reuse
> > of open-source plug-ins for other browsers (like Mozilla or MSIE).  If the
> > Atari browser would use the same plug-in API as Microscape browsers it
> > would be a lot easier to write plug-ins (I'm not talking of jpeg or png
> > plug-ins but more complex modules).  It would also be easier to convince
> > 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.

Ciao

Guido
-- 
http://www.stud.uni-saarland.de/
Send your spam to president@whitehouse.gov and your replies to
mailto:guido at freemint dot de