[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