New Message: Re: Frontier address limitations

webmaster at userland.com webmaster at userland.com
Thu Jul 21 02:37:49 CDT 2005


A new message was posted:

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

By: Jake Savin (jake at userland.com)

/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./

If I understand you correctly, then I think the answer is that the bug is not as widespread as it might first seem. Frontier cannot properly handle addresses longer than 256 (255?) characters when the address value is part of a list or record. It *can* handle longer addresses if they're stored as an address entry in a table, and likewise in a local variable (which is actually in a table which represents variables local to the stack frame).

So I think as long as you're not ever converting to or from an array or record, you should be ok.

I'm not an expert in xpath by any stretch, but would be interested in learning more as long as it wouldn't take forever and a day. If you're working on generalized xpath parsing utilities, we might consider your additions for release as part of a sub-table of system.verbs.builtins.xml, say system.verbs.builtins.xml.xpath. I'd have to know more about how they work first though.

Incidentally, I recently wrote a plist to table converter. If you're unfamiliar with plists, they're an Apple XML invention which are commonly used to store user preferences and user-level application data on MacOS. They also store iTunes playlists on both Mac and Windows, though that's not what I wrote the code for. Rather, I'm working on an upgrade to suites.commercial, which can handle bundle-ized applications as well as the newer plist-based AppleScript dictionaries. I plan on finishing this up and releasing it as soon as I can pop up for air on some other more pressing stuff. Look for it in 9.6. ";->"

-Jake

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




More information about the Manila-Server mailing list