[Registry-dev] Extensible search API - coming back

[Chathura C. Ekanayake]

Glen Daniels wrote:
> 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!

IMO we can represent collections by Resource objects. Java has also done 
exactly the same thing. It represents both files and directories using 
the java.io.File class and provides isDirectory() method to determine if 
the object is a directory.

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

If we represent directories by Resource objects, we can put the child 
paths as the content. I think this is more meaningful, as the content of 
a directory is its children.

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

IMHO if each search result can be located by a URL, we can simply return 
a collection resource as the result. The content of that Resource 
contains a String[] of result URLs. So we don't need an explicit 
ResourceCollection class.

>
> * 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 can put additional meta data in resource properties.

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

+1.

>
>> 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
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>