Hi folks, What about forking this discussion to the w3c-dist-auth mailinglist? That would give the chance to clearify and track these issues in the binding spec...
Cheers, Daniel -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Miguel Figueiredo Gesendet: Donnerstag, 24. Februar 2005 20:51 An: 'Slide Developers Mailing List' Betreff: RE: Binding store and DASL extensions Hello lisa, Well, let me give you my thoughts on this. I believe that a resource with multiple bindings on it, should maintain the same properties list. In theory a binding is the reference for the resource, and the binding is just that: a pointer. So the information and meta-information should be stored in the resource and not in its bindings. If we agree on this, it means that getlastmodified or displayname should have the same values if obtained by any of the resource's bindings. Means also that, if we edit a resource by means of bind A, the getlastmodified value obtained by bind B should have the same updated value of getlastmodified when the operation on bind A completed sucessfully. If we are talking about the etag, the value must contain the unique identifier of an http referenced object, witch I believe must be different for every bind of the same resource. That brings about a idea of mine of making each binding of a resource have it's own displayname property. Why couldn't we add metainfo associated with each bind information contained inside resource's bind property? I believe it's the DAV:segment xml element I'm talking about: adding in there metainfo like displayname and etag. Just my thoughts, Miguel Figueiredo ____ The binding spec is a little ambiguous about whether a property may have different values on different bindings to the same resource. I worry about this because I suspect client implementors might make assumptions about how to synchronize resources for offline usage -- will a client assume that for a set of bindings that are synchronized, that only one copy of the 'displayname' property needs to be stored? (Even more important a consideration for etags and getlastmodified, of course) Lisa On Feb 23, 2005, at 2:38 AM, Miguel Figueiredo wrote: > > Thank you for the response Stefan! > > Well, we are not using lucene with DASL, not yet anyway. We just set > up the > bind store with that optional > classname="org.apache.slide.store.BindingStore" attribute and > everything > else is very straight forward (txFile store). > > But, returning to the binding issue. I agree with you in that we can't > use > the displayname like we would for a name of the resource: a resource's > href > xml element can be anything like you presented, and still reference > the same > resource. So, it's not possible to give a common name to all bindings > of the > same resource. This is ok with me. > > Anyway, how about filling up the displayname, by default, with the > ending > substring of the binding's href? > > Like I said previously, I didn't find anything about the displayname > property on a resource (or more precisely, on a resource's bind) in the > matter of if it is optional or if it is mandatory, so perhaps this > isn't a > bug. But Slide could still fill up the binding's displayname at its > creation, if for anything, for consistence sake with the default > store. This > could also help me and others when using the Bind store and DASL: we > could > use the displayname like a name for the resource, even if it wasn't > (with > some planning we can do it like it was really its name). > > > If this feature is ok with you and the developer team, perhaps I could > contribute with a patch if you guys are overwhelmed. I believe it > would be > very easy to enhance the store. > > Many thanks, > Miguel Figueiredo > > __________________ > > > The Problem with BINDing and the displayname property is that the > property > cant > used a something like a "filename" of "name of the resource", because > different > bindings may have diffrent last segments in its uri, e.g. > /files/docs/abc.txt and /files/other/def.txt > can be bound to the same resource. So you cant determine the > "filename" at > the > resource in general. > > An other point. What DASL impleemntation do you use? AFAIK at least the > lucene base indexer is not yet prepared to work with binding stores :-( > > Regards, Stefan > > > Miguel Figueiredo wrote: >> Hello folks, >> >> I'm wandering if I found a bug at the binding store. When using it, >> each >> resource does not have a DAV:displayname property - is that a bug? >> Could > not >> found anything in the spec saying that the DAV:displayname is >> optional nor >> if it was mandatory, so I'm kind of puzzled on this. >> >> Well, when trying to use DASL, we have found out that it's not >> possible > to >> do a search in resources, and include the href 'property' in our >> search >> options. That is, we could not find any resource, using DASL, and >> based on >> the DAV:href xml element, because this element is not considered as >> part > of >> the resource properties like, for example, DAV:displayname is. This >> is ok, >> that's what's expected from the spec. So we started using the >> DAV:displayname to find out about the resources names, since that >> property >> had the last substring of the uri of the resource, containing what we >> recognize as name of the resource. >> >> Problem is, when using the binding store, each resource won't have the >> DAV:displayname, so we can't search for resources based on their >> names... >> (lol) :) >> >> Will someone agree with me on adding the same behavior of the default > store >> to the binding store? Maybe it's not a bug since nothing is said >> about if >> displayname is mandatory, but at least it should be added in the >> binding >> store for consistancy sake. >> >> Many thanks, >> Miguel Figueiredo >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > -- > Stefan L�tzkendorf -- [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
