[OS3 Proposal] Persistent Query Service
James Snell
Friday but I wanted to pull it out as a separate item.
As we are all painfully aware, searching within OS definitely needs
some more work. It does not need to be too overly complicated tho.
Among other things, I would like to propose a new Persistent Query
Service as a Core API. The service would allow Queries to be created
by a client, then accessed repeatedly later via GET requests... All
queries would be specific to individual users/resources... For
instance:
POST /api/query/@me HTTP/1.1
Host: example.org
Content-Type: application/json
Authorization: Bearer 123456abcdef
Link: <http://opensocial.org/specs/3.0>; rel="implements"
{
"displayName": "My Search",
"objectTypes": ["person","event","file"],
"filters" : [
{"field":"displayName","op":"contains","value":"foo"}
]
}
I'm still working on the specific Query document format...
essentially, it would be an extensible JSON structure that would allow
basic kinds of filters to be established for the query.
The server would create the query and hand me back a URL for it...
HTTP/1.1 201 Created
Location: /api/query/@me/query-id-1
Afterwards, I can perform a GET at any time on that URL to get the
current results.. which would be returned using the basic Activity
Streams collection format...
GET /api/query/@me/query-id-1 HTTP/1.1
Authorization: Bearer 123456abcdef
...
HTTP/1.1 200 OK
Content-Type: application/json
Link: <http://opensocial.org/specs/3.0>; rel="implements"
{
"displayName": "My Search",
"objectTypes": ["person","event","file"],
"filters" : [
{"field":"displayName","op":"contains","value":"foo"}
],
"items" : [
{
"objectType":"person",
"displayName": "Foo Bar Baz",
...
},
{
"objectType":"event",
"displayName": "Foo Event",
...
}
]
}
To modify the query later, I can simply perform a PUT or PATCH
operation on the Query URL, or send a DELETE.
To determine which queries are available to a given resource, the
server would provide a single non-modifiable query for all
resources... e.g.
GET /api/query/@me/@queries HTTP/1.1
Authorization: Bearer 123456abcdef
Which would return a collection of the resources available queries...
HTTP/1.1 200 OK
Content-Type: application/json
Link: <http://opensocial.org/specs/3.0>; rel="implements"
{
"displayName": "My Queries",
"objectTypes": ["query"],
"items" : [
{
"objectType": "query",
"displayName": "My Search",
"objectTypes": ["person","event","file"],
"filters" : [
{"field":"displayName","op":"contains","value":"foo"}
],
"url":"http://example.org/api/query/@me/query-id-1"
},
]
}
The system would obviously be free to provide it's own collection of
persistent queries. For example, a Forum or Community app built on the
OpenSocial server would be able to create it's own queries for
specific resources... listing the members of the community, for
instance; listing the most recent messages; returning the URLs of all
the profile photos for the members of the forum; etc... the list can
go on. The point is that the Query Service would provide a single,
consistent interface through which persistent search operations can be
provided.
- James
Laurent-Walter Goix
apart from avoiding repeating the specific query in each request, it
would be interesting to explore the way to activate a real
subscription and be notified asynchronously (e.g. based on a change in
the information rather than on a new activity/update). this is a
typical use case from the mobile world we are examinating, where push
capabilities can be leveraged. but generally this could be extended to
other bindings, web sockets, event sources or "simple" callbacks.
would it be reasonable to expand this concept/study to accommodate
such a use case?
On Feb 6, 6:35 pm, James Snell <jasn...@gmail.com> wrote:
> Ok, this particular item was bundled up in one of the posts I made on
> Friday but I wanted to pull it out as a separate item.
>
> As we are all painfully aware, searching within OS definitely needs
> some more work. It does not need to be too overly complicated tho.
> Among other things, I would like to propose a new Persistent Query
> Service as a Core API. The service would allow Queries to be created
> by a client, then accessed repeatedly later via GET requests... All
> queries would be specific to individual users/resources... For
> instance:
>
> POST /api/query/@me HTTP/1.1
> Host: example.org
> Content-Type: application/json
> Authorization: Bearer 123456abcdef
> {
> "displayName": "My Search",
> "objectTypes": ["person","event","file"],
> "filters" : [
> {"field":"displayName","op":"contains","value":"foo"}
> ]
> }
>
> I'm still working on the specific Query document format...
> essentially, it would be an extensible JSON structure that would allow
> basic kinds of filters to be established for the query.
>
> The server would create the query and hand me back a URL for it...
>
> HTTP/1.1 201 Created
> Location: /api/query/@me/query-id-1
>
> Afterwards, I can perform a GET at any time on that URL to get the
> current results.. which would be returned using the basic Activity
> Streams collection format...
>
> GET /api/query/@me/query-id-1 HTTP/1.1
> Authorization: Bearer 123456abcdef
>
> ...
>
> HTTP/1.1 200 OK
> Content-Type: application/json
> {
> "displayName": "My Search",
> "objectTypes": ["person","event","file"],
> "filters" : [
> {"field":"displayName","op":"contains","value":"foo"}
> ],
> "items" : [
> {
> "objectType":"person",
> "displayName": "Foo Bar Baz",
> ...
> },
> {
> "objectType":"event",
> "displayName": "Foo Event",
> ...
> }
> ]
> }
>
> To modify the query later, I can simply perform a PUT or PATCH
> operation on the Query URL, or send a DELETE.
>
> To determine which queries are available to a given resource, the
> server would provide a single non-modifiable query for all
> resources... e.g.
>
> GET /api/query/@me/@queries HTTP/1.1
> Authorization: Bearer 123456abcdef
>
> Which would return a collection of the resources available queries...
>
> HTTP/1.1 200 OK
> Content-Type: application/json
James Snell
don't get too far away from the fundamentally basic problem of
searching in OpenSocial. As long as we're sure those fundamental cases
are still met and done so in a way that is simple, exploring the
notification model is certainly a very desirable option... to me at
least.
> --
> You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
> To post to this group, send email to opensocial-an...@googlegroups.com.
> To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>