If for any reason the tab character proves to be unusable, you might choose the "pipe" character "|" just above the enter key with the backslash. I too like simple name/value schemes for data where possible. Generally they're much, much faster than parsing xml if nesting isn't an issue. As an aside, I recently read a comment by will shipley of Delicious Monster where he was responding to criticism regarding the "Delicious Generation" eye candy trend where he was discussing improvements to the Delicious Library application. It turns out per his comment that the primary reason it bogged down with larger collections was related to writing out all the xml info, and he was moving to a DBMS backend. For those with longevity in the field, plain text name/value or header/body approaches have worked in the past for large large sets on machines with far less capabilities. The move to XML irritated me because it put the onus of ordering the data to fit a consumer on the producer in an "expensive" way in the name of advancing an ephemeral common exchange. I have always felt that the producer should put out the data in the easiest method and if it is of sufficient value to the consumer, then the parsing could be handled from that end... Generally, it will be in the interest of both sides, but there are far faster grouping and parsing methods than full xml for most kinds of data sets. Real time trading apps used to run quite fast on simple name value data exchange, but with the introduction of xml getting the communication right means wading through pages of crud delimiters.... I pine for the simpler times....
Wayne On 6/12/07, David Bovill <[EMAIL PROTECTED]> wrote:
On 12/06/07, Jim Ault <[EMAIL PROTECTED]> wrote: > > The Rev filter command is very fast and I would recommend considering it. > The one caution is to replace null with empty, if this is a possible > character. That would only be in binary data? Databases? When would you get null values - certainly nothing from within Rev I think? Not in XML? In my case, some of the content text can have "<" or "/" or ">" in the body, > so I avoid those. You seem to have control of your content, so it will > not > be problem for you. Same with me - content comes mainly from within a Rev application, or carefully picked external files, I am thinking of base64 encoding everything else - though I have to figure on whether to use urlEncoding (forgotten the issues). I am trying to figure which sort of text / xml files I will need to encode - maybe any XML files with CDATA sections.... Arrays are very fast and can remove duplicates. > Also think of compound keys for the arrays, which I use for > forward+reverse > lookups in the same array. > > Moving data around, consider built-in > compress(var) > decomprerss(var) Yes. So if there is a 3 part strategy: 1. Safe one line stuff without funny chars = > create "name [tab] value" line 2. htmltext and some other types of "xml" ish data without tabs - strip out CR and do as above 3. Anything else base64 encode (or should that be urlEncode) I am not clear yet on the details of XML without CDATA - with regard to non-existence of tabs and CR in content? Are they always escaped - if so then stripping out CR and maybe tab as well to make one line works. _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution