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
