Re: [MiNT] mint web/apache idea

["Stanislav Opichal" <opichals@alpha.inf.upol.cz>]

Hi!

> Good idea but far too complicated.  If you write a w3c-libwww based ovl
> you can do that better.  The library has a crude HTML parser (sufficient
> for filtering out images, sound, video and so on).  You can simply
> prefetch these files.  The library also comes along with its own cache

Yes, I think this is the only way to go to have a good modern WEB browser -
go the w3c way.

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

> Today I wouldn't start such a project again because CAB development is
> dropped and CAB's html parser is already behind.  I don't see a point
> trying to improve CAB.

Rigth! CAB is death and thus it shouldn't be taken in mind. At least until
some source parts are not available.

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

> > Even more important than volunteers is the coordinator.
> > Without a bomb-proof design and a skilled programmer to
> > coordinate the efforts such a project is doomed.

Yep.

> Another prerequisite for such a project (I know that from my Sparemint
> experience) is an internet site that hosts the development.

Definitely, as I've said at the beginning. At least mailing list.

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

> 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.
MagiC?
    solution: port the libwww to use it with MagiC and everything should
work then.

Other thing is the rendering machine... It should be highly module
divideable (possibly .SLB as the standard PlugIn interface) architecture to
allow the whole programming distribute all round the Atari scene. We should
definitelly go into the Amaya (Mozilla, CAB? (Alexander's will and or trust
to developper team?), and other browser sources)
Here my question is: Is the Highwire (rumorously devellopped WEB browser)
capable to run on both OSes and or is there a possibility to write e.g. my
own
JPG -> monochrom module (could be written in really efficient way to the
standard
workflow like unpack the whole JPG (all colors) and then dither the whole
thing)
instead of the default one (or none in the beginning).
There can therefore be some kind of language PlugIns like JavaScript and
other. Concerning this there is also need to propose "bomb-proof" and
flexible,
but FAST, PlugIn interface and other design.

best regards

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