RE: [xdi] Persistent Search

["Barnhill, William [USA]" <barnhill_william@bah.com>]

Agreed. This is one of the reasons why I proposed that XDI messaging be asynchronous back in July 2010 (see below for excerpt).  The kind of search this talks about would in XDI be a normal search request. The persistence, refresh period, and conditions for termination of the persistent request would not be in the request itself, but in the link contract that governs it. 

Excerpt from pervious message...

On Fri, Jul 9, 2010 at 12:09 AM, Barnhill, William [USA] < barn...@bah.com> wrote: 
Another topic discussed on today's call was that we haven't addressed whether XDI messaging is inherently asynchronous or synchronous, and if asynchronous what the method for doing that will be. 

My personal POV is that I think it should be inherently asynchronous to match the need for XDI service interactions being distributed and concurrent, so that we avoid blocking. The model I suggested, ignoring for now link contracts, was: 

1. A request initiator (R) discovers the XRI where requests for a particular service provided by a service provider (P) are added, most likely a publicly writable but not readable endpoint 
2. R then adds an XRI for their request to the graph at that location, this XRI points to a graph under their data authority (or a broker's data authority) that represents the request 
3. When P is ready to service the request it reads the request from R's graph, services it 4. P then finds under the request graph where the result is to go, or if not specified writes to the graph in a specific location the XRI where the results are in P's graph 

I think this model has the advantages of being asynchronous, designed to be suitable for a distributed worker model, and non blocking. During the discussion I came to the view that maybe it should support both sync and async, as some use cases will not need/want async. My preference though would still be for a purely async model. I also think this will help XDI adoption, given the current drive towards languages that handle concurrency and non-blocking operations as the preferred method for doing things, such as Erlang, Node.js, Scala, Go, and Clojure. 

The model above has the disadvantage of increased round-tripping, but I suspect the view will be that given the scalability benefits from async the round tripping costs are outweighed. 

________________________________________
From: Michael Schwartz [mike@gluu.org]
Sent: Tuesday, March 22, 2011 10:10 AM
To: xdi@lists.oasis-open.org
Subject: [xdi] Persistent Search

It would be awesome if XDI supported this type of "persistent search" :
    http://www.ietf.org/proceedings/50/I-D/ldapext-psearch-03.txt

- Mike



--------------------------------------------------------------------------------------

Michael Schwartz
Gluu
Founder, CEO
mike@gluu.org
https://www.gluu.org
+1 646-810-8761



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php