Subject: RE: Future of DSSSL: What about PDF? From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Sat, 6 Mar 1999 17:20:10 -0500 |
Hi Brandon <YourComment> Beyond all this, however, I'd like to find out what you all think of an alternative to the closely coupled formatter and engine. I recall that we had a discussion along these lines some months ago, and one of the alternatives was to create higher level FOs that could "encapsulate" some of the more complicated formatting tasks which might otherwise require such a coupling with the formatter. I see two main advantages to this. First, we avoid the complexity of coupling the formatter to the engine. Second, and this is one that the coupling solution can't even touch, is the fact that it allows for a complete separation of the styling and rendering processes. As an example, what if you're dealing with a client/server situation where you've got the DSSSL engine doing the styling on the server, and an advanced rendering engine on the client, and there's no way for the two to communicate beyond a simple transfer protocol (such as HTTP). This could well be the case for a client behind a firewall. Another possibility would be a situation where the DSSSL processing is done in batch mode, but the rendering is done on demand, possibly including dynamic information, such as the current date, each time. This idea is, of course, based more on general design concepts than on practical knowledge of the problems which these approaches would need to solve, so I'm certainly wide open to any comments on the feasibility of this idea. </YourComment> <Reply> You would be surprised of how well a dsssl engine can transform a SGML or XML document into HTML for browsers delivery. We are currently testing a SGML/XML server running under IIS 4.x (we are porting it to Apache too) and the result is surprising, without optimization we get faster results or similar results to XSL based scripts with Microsoft XSL engine. With optimization, it could be faster. For an average loaded server, the result is reasonnable. For heavy loaded servers we plan to use the groveobjects (mentioned in the previous post) with permanent storage. So, you store you SGML/XML document on the server. It is parsed on included on a grove object hierarchy. Then, the dsssl engine process directly on this grove instead of reparsing the document each time. The result is a HTML document sent to the browser. Early testing match ASP processing. So the trick on the server is to have the document pre-parsed and stored in a "permanent" grove. The dsssl engine intereact with this grove. In that case, we don't use a secondary formatting objects grove but instead send directly the HTML+CSS FOs. A good point on this architecture is that both a XSL and a DSSSL engines could make processing on the same document grove. </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: Future of DSSSL: What about PDF, Brandon Ibach | Thread | Re: Future of DSSSL: What about PDF, Carlos Villegas |
RE: Future of DSSSL: What about PDF, Didier PH Martin | Date | The simple-page-sequence FO vs the , Didier PH Martin |
Month |