On Tue, 2002-01-29 at 08:15, Derek Atkins wrote: > Dave Peticolas <[EMAIL PROTECTED]> writes: > > > Thanks, this looks like a great start. > > Thanks. > > [snip] > > I realize that isn't list isn't comprehensive, but we > > should support all the basic kvp types, including int64 > > and double. Also, boolean would be good, too. > > True, but this list is "comprehensive" in that it covers everything > that the current Query can cover. But yea, we should be able to > cover all the KVP types.
Oh, well in that case you're just wrong :) You missed the 'kvp' query api, unless you were looking at the stable sources. > [snip] > > Or just add a 'character' type, maybe. > > That would work, too, and the predicate data can be a "list" of > "wanted" characters. > > > > The attached files are the current (incomplete) header files. Please > > > let me know what you think so far. > > > > From my reading of the API, it looks like each object > > data member (account name, account code, etc), is registered > > individually. Is that right? What about dynamic kvp data? > > Yes, you read it right. Keep in mind that each 'type' defines it's > own predicate-data object.... > > I need to think about the kvp data. My first off-the-cuff idea would > be to define a 'kvp' type, register the kvp-getter, and in the > predicate-data define the slot/frame name, type, and data. Or perhaps > have it recurse a bit? Like I said, I have to think about how to > handle kvp data. Do you have any ideas? Well, first take a look at the existing api. dave
signature.asc
Description: This is a digitally signed message part
