Re: About Constructions rules

[Chris Maden <crism@xxxxxxxxxxx>]

[Brandon Ibach]
>    Valid point, but unless I'm being naive here (which is a
> reasonable possibility :), I don't think it's insurmountable.  The
> idea of being able to start processing before the entire document is
> parsed is very nice, but does Jade really do this?

I believe so.  I don't remember the details, but from my brief,
abortive attempt to read the sources and build a grove builder, Jade
uses a blocking, multi-threaded ... um, interface? to allow styling to
start before the source grove has been completely built.

>    It would have to happen one of two ways.  Jade would have to be
> multi-threaded, with separate threads for the parsing (and grove
> building) and processing.  I'm fairly certain this is not the case.

I believe it is, but I am not certain.  Ah... from jadedoc/jade.htm:

   Jade includes the following components:
     * An abstract interface to groves. This is designed to be
       implementable on top of a database, in addition to simple
       in-memory implementations.
       The source is in the grove directory.
     * An in-memory implementation of this interface built with SP.
       This is multi-threaded (on Win32 only at the moment): the grove
       can be accessed before it is complete and access to a property
       of a node will block until that property becomes
       available. This allows the style engine to produce output
       before it has read all the document.
       The source is in the spgrove directory.

It's only multi-threaded on Win32, which I'm not using, and if you
aren't either, then you might not have noticed this.

> The alternative would be that Jade parses the document on an
> as-needed basis.  It's possible that this could be happening, but is
> it?  Matthias, Didier, Avi, etc?  Can you answer this?

Not as-needed, but just that it (on Windows) styles without waiting
for the entire document to be parsed.

>    Whichever (if either) the case is, I think there's a way to fit
> query construction rules in without needing to have the entire
> document parsed before you evaluate it.  Just as the parsing is done
> piece by piece, could not the query evaluation be done as well?  In
> other words, as much as possible, build up the result node list as
> you build up the source grove?  Keep in mind, the node list as a
> whole is irrelevant to the query rule.  All we care at any given
> point is whether a certain node is in the list, and if we're to the
> point of processing that node, chances are (though not certain) that
> enough of the document has been parsed to have been able to
> determine whether that node is in the result list of the query.

But of course, you have to check every node against your list of
queries.  With only element construction rules, a very small
percentage of all nodes (usually) are candidates for a given
construction rule.  Evaluating every node will hose your performance.
You can compile queries, of course, but with arbitrary possible
expressions, you'll always have potential ratholes.

-Chris
-- 
<!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN">
<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>


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