Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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: 

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

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

Code Block
  GET /api/query/@me/query-id-1 HTTP/1.1 
  Authorization: Bearer 123456abcdef 

... 

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

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

*Strawman* Query Document Syntax

...