[Registry-dev] Extensible search API - coming back

[Sanjiva Weerawarana]

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!

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

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

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

Sanjiva.
-- 
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
email: sanjiva at wso2.com; cell: +94 77 787 6880; fax: +1 509 691 2000

"Oxygenating the Web Service Platform."