[Registry-dev] Extensible search API - coming back

[Chathura C. Ekanayake]

Sanjiva Weerawarana wrote:
> Chathura C. Ekanayake wrote:
>> I like the idea proposed by Glen, which is to always return a 
>> collection of resources.
>> Then we can use below API methods (with some modification to the API 
>> proposed by Glen),
>>
>> /**
>> * Queries can be stored in any path. If we want to support user 
>> specific queries we can store them in a path similar to 
>> "/users/chathura/my_top_rated_mashups".
>> * Then if someone (e.g. mashup site) wants to execute user specific 
>> queries, he can execute the queries in the currently signed in user's 
>> path.
>> * i.e. we are supporting user specific queries by convention, not by 
>> logic.
>> */
>> public void defineQuery(String queryPath, String query);
>
> 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!

+1. Cool.

>
>> 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?).

If we return a collection resource, we have to get each result using 
separate registry.get() calls. I used Resource[] only for optimizing 
that. But we can replace it with a collection resource containing URLs 
of all result resources.

>
>> 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).
>
> 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?

Yes :)

>
> - 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
>     Return all the tags that have been applied on this resource as an 
> XML file format we define (?)
> - 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 (?)
>
> 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.
>
> 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?

We can get the properties in the same way we get comments or tags. i.e. 
/a/b/r1?properties will return the properties of the resource /a/b/r1.

Thanks,
Chathura

>
> Sanjiva.