Easy, readable and fast text based format for Rev?

[wayne durden]

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 <david at openpartnership.net> wrote:
>
> On 12/06/07, Jim Ault <JimAultWins at yahoo.com> 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>