[Registry-dev] Extensible search API - coming back

[Glen Daniels]

Hi Sanjiva:

Sanjiva Weerawarana wrote:
> BTW, at a REST level- I do have to agree that a directory is simply a 
> resource with a different representation. In fact, we can drop 
> "isDirectory" and simply have a standard media type we return.

That's exactly what I'm proposing, only with one extra step which is to 
notice the media type (or the XML root element) and return a Java object 
  with convenience methods for walking the collection instead of a 
regular Resource.  We could also do this by having the collection be the 
content object instead of the Resource object itself, but I like the 
simplicity of:

ResourceCollection coll = (ResourceCollection)registry.get(dirPath);
while (coll.iterator().hasNext()) ...

vs.

Resource r = registry.get(dirPath);
ResourceCollection coll = (ResourceCollection)r.getContent();
while (coll.iterator().hasNext()) ...

> In effect that's what Apache HTTPD does when you ask it to auto generate 
> the list of files for a dir when there's no index.html.

Yes, and we want an API that recognizes this and lets you operate on the 
children.

> So for example, if we return an Atom feed for a directory, we could have 
> some extra parameter for the content type to indicate this is directory 
> and not just any old feed.
> 
> OK so I lied; I am (at least partly) arguing for the current design ;-).
> 
> I remember being torn by Chathura's argument - so we'll let him tear you 
> apart inside too ;-).
> 
>>>> In all above types, we can put the main data part (e.g. comment 
>>>> text, tag string, rating value) as the resource content and
>>>> put all other data as resource properties (e.g. number of taggings).
>>
>> See above - I think with a collection it's fine to include metadata in 
>> the result data.
> 
> For a collection its fine, but I don't understand what resource 
> properties is for a resource and how you get at that. GET /a/b/r1 must 
> simply return whatever representation the system can based on the 
> content negotiation headers the client has put (Accept: whatever).

Yes, and if there are related things then the client might get them by 
doing something like GET /a/b/r1;stats or the equivalent.  But the 
associated data has to essentially be its own resource with its own 
representation.

To quickly cover the last couple of points:

While tagging comments might seem overboard, what about commenting on 
comments?  Isn't that how discussions work?

My issue with the query string is more about collisions than anything 
else.  At some point we might be sourcing dynamic stuff in the registry 
which itself wants to process query strings.  If our registry framework 
depends on the query string then name collisions and other problems 
might occur down the line.

--Glen