KVP and data that contains a forward slash

[Derek Atkins]

John Ralls <jralls at ceridwen.us> writes:

>>> Thanks for catching that. We absolutely don't want to create deep
>>> keys, performance will suffer in SQL. Please file a bug so that I
>>> don't forget.
>> 
>> Don't we still have a single function that parses a full key-path from a
>> single string?  How would it know how to part something like:
>> 
>>  /foo/bar/Assets/Bank  into  [foo] [bar] [Assets/Bank] ??
>
> Yes, that's the problem. It's not used for matcher tokens in maint but
> is in master, and it shouldn't be.

Ah, well that would be the problem :)

>       I can't off-hand think of a case
> where using a file path for a KVP key would make sense, but if there
> is then it shouldn't have that set of functions used on it either.

Originally the KVP path was supposed to be a file-system.  So if there
is a desire to move away from that, then we should be explicit about it.

> Most of our existing use of nested KVP isn't necessary anyway, but
> changing it will require a new file/db version and conversion
> routines. No point in introducing new nesting though, and besides that
> would also create a file incompatibility between 2.6 and 2.8.

I would disagree; it's nice to have some nesting (certainly within the
XML framework) to make it easy to remove whole KVP subtrees.  When you
view KVP as a file system then it makes total sense to have nesting, and
all the benefits that come with it.

> Regards,
> John Ralls

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available