RE: About the source library

Subject: RE: About the source library
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Fri, 30 Apr 1999 11:42:56 -0400
Hi Sebastian,

<Comment>
as David says, I think that James should be given a chance to have a
good think about this. If he is happy to hand over Jade to a Web-based
maintenance committtee, all well and good. If not, it would only be
polite to start a new `product' with a new name (albeitt based on
James' code, since he is generous in his licensing).
</Comment>

<Reply>
I agree with you. So let's compose a letter to James to ask him what are his
thoughts on this.
</Reply>

<comment>
of course, if someone volunteered to rewrite Jade so that the backends
were something like plugins which could be maintained entirely
separately.....
</Comment>

<Reply>
This is not an easy process :-). I am still struggling to find a way to
create an interface between different modules but the C++ inheritance and
the application classes (and also that you have to do code archeology :-) do
not facilitate this. I am actually looking at grovea code to try decoupling
grove from style. (but this is archeology and it takes time :-)

The idea is to try to have three family of modules:

a) Grove/DOM
b) Script engines
c) formatting object mappers (backbends)

This way, for example, a XSL or DSSSL processor could be running on a Grove
(the grove being created either by a XML or SGML document). And formatting
objects mappers called dependent of the type of format expected. I am
currently experimenting with a DOM mapper. This mapper directly creates DOM
objects within a browser. As you know, actually, Jade creates a HTML+CSS or
SGML file. But this file after being created has to be interpreted again to
be rendered. If the backend directly creates DOM objects, the second
interpretation phase becomes obsolete and thus, the total rendition time
within a browser could be accelerated.

A good candidate for module interface is XPCOM. Contrary to CORBA, XPCOM has
a single binary signature and thus, even if modules are created with
different compilers, we can have them to interface because of this common
binary signature. Also, because the integration with Mozilla is greatly
simplified.
</reply>

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread