I might be a little newbish here, but then why not an Iterator? The iterator lives on the server and is accessible through the REST interface, providing a advance and value method. It either operates on a stored and once-created-stable result set or holds the query and evaluates it on demand (issues of changing underlying graph included).
The client can have paginator functionality by advancing and derefing the iterator n times or streaming-like behaviour by constantly pushing the obtained data into a queue and keep on going. If the client does not need the iterator anymore he simple stops using it and a timeout kills it eventually on the server. a client-callable delete method for the iterator would work as well. Georg On 22 April 2011 18:43, Jim Webber <j...@neotechnology.com> wrote: > Hi Michael, > > > Just in case we're not talking about the same kind of streaming -- > > when I think streaming, I think "streaming uploads", "streaming > > downloads", etc. > > I'm thinking "chunked" transfers. That is the server starts sending a > response and then eventually terminates it when the whole response has been > sent to the client. > > Although it seems a bit rude, the client could simply opt to close the > connection when it's "read enough" providing what it has read makes sense. > Sometimes document fragments can make sense: > > <results> > <node id="1234"> > <property name="planet" value="Earth"/> > </node> > <node id="1235"> > <property name="planet" value="Mars"/> > </node> > <!-- client gets bored here and kills the connection missing out on what > would have followed --> > <node id="1236"> > <property name="planet" value="Jupiter"/> > </node> > <node id="1237"> > <property name="planet" value="Saturn"/> > </node> > </results> > > In this case we certainly don't have well-formed XML, but some streaming > API (e.g. stax) might already have been able to create some local objects on > the client side as the Earth and Mars nodes came in. > > I don't think this is elegant at all, but it might be practical. I've asked > Mark Nottingham for his view on this since he's pretty sensible about Web > things. > > Jim > > > > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
