I'm not sure I understand your arguments against using the MetaData stuff I wrote. You listed two reasons, doubling the number of disk writes on update, and public methods for changing metadata values. You also said that in your application, you'll need "requires per-document metadata [that is] likely to change with each update/save." So, you'll be bitten by the your first objection, doubling disk writes.
As for public methods for changing metadata, it is true that there are such methods. The concept of the MetaData design that David Ku and I implemented is that there are 3 types of metadata stored. First, there are "system" elements, like last modified time, last access time. These are handled by Xindice. Second, there are "attributes", which is a big Hashtable. This is for the user to specify whatever key-value type metadata (s)he wants that might be app-specific. Third, there is a custom XML document space. This is for the user to specify whatever hierarchical metadata (s)he wants. Therefore, the methods available allow the user to easily add and remove key-value pairs from the hashtable, and the xml document section. There is also code to let the "power" user change system attributes, but you'd have to write the code to call those methods. The XMLRPC methods provided don't provide a way to change system elements. Your application might need some metadata capabilities that are provided by the metadata design and implementation that's in Xindice now. Without knowing more about your requirements, it's hard to say. But I think the current design is pretty flexible, and should provide you with the functionality you need. If it doesn't, then we should identify if the missing piece is related to the design or the implementation of metadata storage in Xindice. If it's the implementation, then we should add it. If it's the design, then we should definitely examine what is wrong with the design. dave -----Original Message----- From: Gary Shea [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 12:07 PM To: [EMAIL PROTECTED] Subject: metadata thoughts I just finished adding binary resource support, and in the process ended up writing an 'inline' metadata facility, where the metadata is stored as a header on the data. The metadata facility is enabled and configured on a per-collection basis. I'm now re-considering metdata, mostly because I don't think I gave the existing metadata facility a fair chance, and want to get some group feedback. There were three reasons why I didn't use Dave Viner's metadata facility: 1) it doubles the number of disk writes needed when a resource is inserted/updated 2) I _think_ the current implementation is not safe for internal use, as I believe there is public code for changing arbitrary metadata values (please correct me if I'm wrong...) 3) sheer laziness A while back there was a metadata discussion on this list, and I've read that discussion. I didn't detect any consensus about what sort of metadata should be supported. It seems clear that collection-level metadata is best off in a 'system table', which Dave Viner's metadata system models nicely. Per-document data is less clear. Some of it will change with every save/update, some won't. The resource type stuff I just did isn't likely to change all that often and might be a candidate for the non-inline metadata, if it is safe from user tampering. On the other hand, I am currently working on Xindice enhancements that requires per-document metadata likely to change with each update/save. I'm interested in hearing arguments pro and con. Regards, Gary
