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

Re: [MiNT] mint web/apache idea



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.

> 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. ;-)

Well, A800 is higly portable Atari 800 emulator (even for F030). BTW: Petr
Stehlik
is taking care about the development - IIRC.

> > 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. ;-)

Sure ;-) Let us left it to later time.

> > 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.

> 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.

> > 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" ?

> 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.

Well, this I'm not familiar with too ;-)

> > 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
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)

> 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?

> 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.

Right.

Stan - JAY Software
opichals@alpha.inf.upol.cz
http://www.inf.upol.cz/~opichals/jay