Thanks for the prompt reply Sean, > The Link header RFC allows you to create your own attributes to the link. > "rel" is a common one that people readily understand (and we use it in a few > cases), but separating out riaktag makes it clear that the usage is specific > to Riak. Most headers will accept extensions, but doing so imply in, i.e., loss of visibility by intermediates. The rel attribute is a standard and has the semantic meaning that I tought the riaktag extension want to express (relations between different buckets?)
> I assume you mean X-Riak-Meta-* headers. These are simple conveniences for > the application programmer to express things that don't require interpreting > the body of the response. You are free to use them, or not. They have no > special meaning from an HTTP perspective, but translate to object metadata > in Riak's storage mechanisms. Yep. Depending on how the user uses it, he might break the interface or not. > The challenge of doing such a thing is to enumerate the other endpoints in a > way that makes sense from a hypertext perspective. I worry about trying to > describe things like /mapred that require POST Well, if you are creating a map reduce, you do not need to describe that it is a POST, the HTTP rfc already did it for us. By simply creating a link to those resources (i.e. the mapreduce control uri), the client knows due to the RFC that he has to POST to create something. > or buckets and keys that > would require expensive listing operations. How are buckets typically accessed? Through URI memorization by the client when he created them? Regards Guilherme Silveira Caelum | Ensino e Inovação http://www.caelum.com.br/ 2010/5/26 Sean Cribbs <[email protected]>: > Guilherme, > > There was probably a reason for that I am unaware of, so what could > prevent using the rel element instead of the custom riaktag attribute? > > > The Link header RFC allows you to create your own attributes to the link. > "rel" is a common one that people readily understand (and we use it in a few > cases), but separating out riaktag makes it clear that the usage is specific > to Riak. > > Also when checking the vclock and etag headers, is it possible to use > the etag and last modified instead of vclocks at all? I know its > supported, but still vclock is mandatory now, correct? > > > The ETag header is a hash of the vector clock, so it is essentially > equivalent, but a smaller form. In my mind they serve different purposes - > vector clock is for tracking lineage of the object, the etag is for > (in)validating caches. > > The meta header could not be contained within the representation > itself? The http provides meta data in a uniform way, allowing clients > to extend it at will seems to make it easy to break this interface. > > > I assume you mean X-Riak-Meta-* headers. These are simple conveniences for > the application programmer to express things that don't require interpreting > the body of the response. You are free to use them, or not. They have no > special meaning from an HTTP perspective, but translate to object metadata > in Riak's storage mechanisms. > > Finally, any interest in creating an entry point for it all? Where we > can navigate to stats, map reduces executed so far and so on? > > > The challenge of doing such a thing is to enumerate the other endpoints in a > way that makes sense from a hypertext perspective. I worry about trying to > describe things like /mapred that require POST or buckets and keys that > would require expensive listing operations. Any suggestions you have are > welcome. > Sean Cribbs <[email protected]> > Developer Advocate > Basho Technologies, Inc. > http://basho.com/ > _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
