I'm sorry, but I just think that "rolling our own" browser is an enormous waste
of valuable time especially given that KHTML and WebCore run well and  reliably
on modern hardware.

GJC

--- Riccardo <multix@ngi.it> wrote:

> Hey,
> 
> it would be nice if you could write gregory a mail about our old 
> discussions of writing a new, pure obj-c and pluggable rendering engine 
> from scratch. Even if you have little time, maybe if we join forces we 
> can make it
> Gregory is thinking again about porting webcore and writing a browser. 
> Although I welcome a browser and WebCore/KHTML is now a quite 
> "industrial strength" core which is suitable for everyday browsing I 
> have some concerns. I don't think webcore is the solution of everything, 
> I think it is not very fast in loading up (not in the render speed 
> itself. but if you open a new render view it takes some time to load.. 
> you notice it when opening a new tab/window on slow machines) and it 
> uses memory badly (noticeable on a low-mem machine especially: browse 
> for one hour, close all windows, leave safari open and you notice you 
> machine swaps as wild anyway, with more ram, it just takes longer to 
> fill up). Of course I know it has a pretty good JS, CSS and it is a 
> quite speedy browser inside Safari. And it is Obj-C++ (I bet gregory 
> wants to use it just to test that crutch, I know his geeky soul) But I 
> fear that getting webcore would remove the motivation for getting 
> another engine, an engine which would be more efficient, more modular 
> (possibly) and pure obj-c... ANd I strongly think a browser core should 
> be very "quick" so it can be used inside a help viewer, an about panel, 
> a generic custom viewer.... wxWidget (with wxHtml) and Java/Swing teach 
> us that. These applications usually don't require the features of a 
> full-blown browser.
> 
> thus the alternatives are
> 
> - webcore. I already commented this
> - gecko. SImilar comments to webcore apply. It consumes more ram and is 
> even slower to startup, but may render faster and is definitvely often 
> more correct in page rendering, since most people which don't use IE use 
> firefox.
> - dillo. I know I was a major dillo fan. But thinking that it would give 
> us a limited browser (although excellently suited for embedded html 
> controls) against quite some work in GTK(fltk in the future?)/GLIB 
> porting. ANd we would need to maintain that port
> - omniweb stuff (before they used webcore). A pure obj-c think, the old 
> sources are still around. A very nice core, although it would need some 
> updating since it supports css1 only essentially and JS is limited. Not 
> extremely fast and the license is possibly a problem.
> - cook ourselves browser, something discussed with you, stefan. DO you 
> remember the concepts of rendering SGML, HTML, XHTML, XML to a common 
> tree? (DOM?) and the having a separate output engine? I remmeber you 
> mentioned some parts of the engine already existing. The definition of 
> the interfaces would allow plugs so a quick write would be possible, 
> with the possibility of future improvments... And make it portable to 
> macosx too!
> 
> I would recomment the last option as now instead of dillo. It would give 
> similar results, but the last approach would be much cleaner and more 
> worth the effort. ALso in the long run it could possibly render pages 
> quite well as we improve the various plugs.
> I  would prefer to start with that before attempting webcore/gecko or we 
> get distracted. CBV also reccoments having an eye on omni stuff....
> 
> of course one question comes out quickly: can a common interface be 
> defined for all those things.. one that encompasses them all without 
> being a bad hack?
> 
> 
> cheers,
>     Riccardo
> 
>