support for RFC 5689
ricardo.rocha at cern.ch
Fri Jan 20 04:17:23 EST 2012
On Thu, Jan 19, 2012 at 11:30 PM, Joe Orton <joe at manyfish.co.uk> wrote:
> On Thu, Jan 19, 2012 at 05:23:55PM +0100, Ricardo Rocha wrote:
>> We have a use case where we would need to pass one or more properties
>> at MKCOL time.
>> Is support for RFC 5689 something worth adding? We could not find
>> support for it in the current implementation. Right now we'll be
>> passing the props in the request string, but what is described in the
>> RFC seems to suit what we need.
> Hi Ricardo - sure, no reason why not. What kind of API would you use
> for extended MKCOL? Can pass in a set of propname/value pairs like
> ne_proppatch(), but adding extra resourcetype elements would be slightly
> more involved. Maybe something like:
> int ne_mkcol_extended(ne_session *sess, char *path,
> const ne_proppatch_operation *ops,
> const ne_propname *res_types);
> whers opts[0..] passes in additional name/value pairs to set in addition
> to the resourcetype, and res_types[0..] passes in any extra resource
> type element names. (I'm not very familiar with 5689, if that makes no
> sense, please say so :)
That looks ok, and matches the example on the spec. We'll review our
exact need again and let you know.
>> On the other hand... we would need something similar on PUT, but for
>> that i don't think we can get away without having to pass the props on
>> the querystring. Any thoughts?
> What's the reference to PUT here?
The use case is pretty much the same. In the same way we need to set a
few properties at the time of MKCOL, we need to set a few properties
at the time of PUT - attach metadata to the entry at the same time as
it is created.
Does this make sense? We could not find any reference on extensions
for this, so right now we simply pass key/value pairs on the
querystring, which we know are properties to be set (and handle this
on our backend).
> Regards, Joe
More information about the neon