New Message: Re: Frontier address limitations

webmaster at userland.com webmaster at userland.com
Wed Jul 20 15:25:09 CDT 2005


A new message was posted:

Address: http://frontier.userland.com/discuss/msgReader$14158

By: Robert Cassidy (rmcassid at uci.edu)

Ah, ok.

Here's what I'm trying to do. I'm using xml to pass information into Frontier and storing it as an xml table, using the xml verbs to parse it.

These tables are getting large and I need to monitor the data within them. One problem with XML is that it can be slow to parse complex trees, so I'm effectively indexing critical bits that are discontinuous in the structure but get accessed frequently. A very simple and consise xml table carries the needed metadata to navigate to the appropriate nodes, but also carries the Frontier address of the node which it can first check to see if it's valid and if it's not, can fall back on the metadata to walk the tree. Speeds things up immensely.

So, walking the tree without getAddressList isn't a problem (I can rewrite the routine myself if that's the main problem), but I need to /store/ the >256 byte address. My question, then is can Frontier not directly address elements that require >256 bytes to describe? Would I need to store an intermediate <256 byte address to a higher-level node and then walk down from there with a table loop? If so, I'm not sure that's going to be too useful considering I can already walk the tree but that's what I'm avoiding. Further, if Frontier has issues with the address size, and not just specific verbs, it doesn't look like I can add elements that need >256 bytes to address, which runs me into a different problem.

BTW, I've added some rough verbs: setAttribute, a getPathAddress verb that will handle attributes (/foo/bar at id), and locateNode that will return a specific node (/foo/bar at id, where id=4). Those are fairly trivial, but the interesting one is a rudimentary xpath parser that will supplant the locateNode: (/foo at id>12/bar=Cheese). It's rudimentary because xpath is nasty to implement in full so I don't support position predicates, booleans and wildcards yet (haven't needed them just yet), but it's SOOO much easier to just shove arguments into the path and get an address list back. If any of these are interesting I'd be happy to send them along.

This is a Manila site.. http://manila.userland.com/.




More information about the Manila-Server mailing list