[Registry-dev] Extensible search API - coming back

[Glen Daniels]

Hi folks!

Sanjiva Weerawarana wrote:
> If we really treat queries simply as resources, do we need this at all - 
> just put(path, resource) will store the resource. The content type of 
> the resource will give the info needed to execute the query later - we 
> can have pluggable query processors based on content type. This is very 
> cool- so we could have Caucho style JSON queries even!

Yup.

>> public Resource[] executeQuery(String queryPath, Object[] parameters);
> 
> Why do we need to return an array? I thought we're dealing with a 
> collection as simply another type of resource ... so its simply a 
> Resource but with the "isDirectory" flag set and with a fixed type of 
> content (an array of strings IIRC?).

OK, let's try this again, once more with feeling! :)

* We should NOT NOT NOT have an isDirectory() flag on Resource.  Ew!

* We SHOULD have a Directory (or whatever) class which extends or
   implements Resource, and also adds methods for walking the children.

* A query result should be a ResourceCollection (or whatever we call
   it)

* IMO we should support each entry in a ResourceCollection having
   both a path (to the associated Resource) and an arbitrary set of
   properties in order to carry metadata.  I believe this is
   compatible with APP's notion (and serialization) of a collection?

We got this mostly right with the first prototype we built while dims 
and I were in Colombo... please let's fix this ASAP.

>> In this approach we should represent all possible search results as 
>> resources. Some possible search results are:
>>
>> Normal resources
>> Comments
>> Tags
>> Ratings
>> Users
>>
>> 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.

> Let me make sure I understand the proposal. Suppose there's a resource 
> /a/b/r1. Are the following the URIs for various things and the return 
> types correct?
> 
> - resource: /a/b/r1
>     Return the natural representation of the resource with the content 
> type properly set
> - comments: /a/b/r1?comments
>     Return an atom feed containing all comments against a/b/r1
> - tags: /a/b/r1?tags

Mostly +1, but I'm still not totally convinced on using the query string 
for this.  Note that other chars like comma, slash and semicolon are 
also available to us, so "r1;comments" or "r1/comments" could be used 
here too.  Both of these have the nice quality that you can easily 
continue the hierarchy downward "r1;comments/2;tags"....

>     Return all the tags that have been applied on this resource as an 
> XML file format we define (?)

Gotta think about this and play with some use cases.

> - tags: /tag/t1
>     Return all the resource (paths) that have this tag applied to it
> - ratings: /a/b/r1?rating
>     return the current average rating for this resource
> - ratings: /a/b/r1?rating&user=xyz
>     return the rating given by user xyz for this resource, if any
> - ratings: /a/b/r1?ratings
>     return all the ratings on this resource as collection of {user, 
> rating} tuples as an XML file format we define (?)

Seems good.

> I am not sure I see how users fit in .. other than as above. That is, 
> I'm not sure something like /user/xyz is a useful resource to have. That 
> can be achieved by doing a query saying "show me everything that user x 
> authored" for example.

I really like /users/xyz as an explicit resource.  That lets you do cool 
stuff in the future (even if we don't yet) like profiles, RDF 
references, etc... and I definitely like that you don't need a specific 
query language in order to know that /users/xyz will link you to 
everything that user has authored - just like tags/tag.

> What did you mean by "resource properties" and how do you envision those 
> being carried to the client when someone does a straight GET on a 
> resource URI?

I may or may not have covered that above.  Chathura?

Thanks,
--Glen