> What do you/we mean by 'metadata'? HTTP headers? WebDAV properties?
> Handling directives? OPES rulesets? All of the above?
Presumably metadata means anything other than the contents, so all of the
above. A generic mechanism for saying "metadata has been changed" could
cover any metadata changes. The information on "how to get the new
metadata" would presumably depend on what kind of metadata there was. So if
the server offers only PROPFIND as a way of getting the updated metadata,
then that means the updated metadata is all available via WebDAV properties.
> > To update metadata, the source server should indicate what
> methods can
> > be
> > used to retrieve metadata. The only method [I'm aware of]
> that can be
> > advertised is WebDAV PROPFIND. However, the ability to
> advertise other
> > methods allows extensibility, e.g. future improvements that
> would allow
> > more
> > efficient replication of metadata than PROPFIND allows.
> Why use a separate method at all?
Not necessarily a separate method. It could be a GET to a separate URL
instead, I guess. I should have said "the server should indicate what
*mechanism* can be used to retrieve metadata".
My basic approach in this proposal is to leave the metadata stuff mostly
unsaid, but have the basic indicators in place. Minimalist. I don't really
understand other metadata scenarios besides the WEbDAV one, but my
assumption is that the intermediary only needs to know the two things
(whether metadata changed, and how to get new metadata).
Keeping the metadata retrieval mechanism out of RUP (other than to name the
mechanism) keeps RUP simpler, IMHO.
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:23:01 MST