[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] mint web/apache idea



Hi,

On Mon, May 15, 2000 at 02:12:04PM +0200, Stanislav Opichal wrote:
> > I've started such a project two years or so ago and it was buried with one
> > of my broken harddisks.  But it already worked (although I probably wanted
> > too much then) in a basic way.
> 
> Well, this is interesting idea... Here, in Czech Republic, we are chating
> about
> how to write a good HTML browser and we are having some ideas, but this is
> probably a thread that needs a separate mailinglist.

Right.  But there is no such mailing-list and I have to keep on polluting
this one. ;-)

> > > web browser for
> > > > Atari only needs a team of volunteers.  It's simply too much for a
> single
> > > > person but for a team it should be possible.
> 
> That's it! e.g. A800 has such a team and it lives and develops further on
> many
> platforms (IIRC).

I don't know A800.  If they are willing to host such a project, why
not. Anyway, we still need some Linus Torvalds that will coordinate
things. ;-)

> > OK, who wants to be the coordinator/maintainer for FAB (Fabulous/Free
> > Atari Browser)?  Joska volunteered to contribute to the ftk (the FAB
> > Toolkit, you don't want to write a web browser without some kind of
> > toolkit), to a certain extent I can give some support for the networking
> > layer (i. e. interface to w3c-libwww which I know a little).  Josephus
> > also offered help in a private mail (I hope he won't mind seeing his name
> > mentioned).  Now go ahead for the rest, Atarians!  Who is going to take
> > the crown?  And who is going to find a better name than FAB?
> 
> OK, I can help e.g. in GEM and other environment programming. Other thing
> like multithreaded plugin handler would be of my interest too.
> BTW: Already proposed name for the browser is BtWeb (Browse the WEB,
> or BTW - "By The Way" ;-) )

I like FAB but finding a good name is only the second hardest problem to
solve. ;-)

> > P.S.: If the browser is based on the w3c-libwww, then it will actually not
> > be an Atari browser but rather a MiNT browser.  In fact, every network
> > application has to decide on some TCP/IP layer and I think that on this
> > mailing list it is probably agreed that this will be standard BSD sockets,
> > i. e. MiNTNet.
> 
> Well, I think this is a thing to be discussed in more details.
> Here, in Czech Republic's Atari mailing list is the browser development
> discussion about how to make such thing and which OS it should support. The
> resulting idea is in my opinion as follows:
> 
> 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
machine without real threading.  The VM has to provide internal threading
functionality anyway.

> 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
to Magic (which would suffice), not the libwww.  But that's ASH's problem,
not primarily ours.  Even better would be for them to make the MiNTNet
drivers run under Magic.  Then we would even have binary compatibility.  I
actually never understood why they had to introduce their own proprietary
and incompatible tcp/ip stack.

> 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
create SLBs.  The GNU linker configured for the target m68k-atari-mint 
will compile out of the box on almost every Unix system.

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.

In fact, you don't really need shared modules for plug-in
functionality.  It is sufficient if they are loadable and relocatable and
that is quite trivial to realize with the existing tools.  Simply use the
normal executable format (without startup code), load and relocate
it.  You will seldom run multiple instances of the browser and thus
sharing is no real issue.  Nobody ever complained that CAB overlays are
not shared objects.

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