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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: About the source library, Sebastian Rahtz | Thread | RE: About the source library, Sebastian Rahtz |
Re: About the source library, Glauber Ribeiro | Date | Re: About the source library, Sebastian Rahtz |
Month |