hi christian

currently RepositoryService#getItemInfos(SessionInfo, NodeId) is
defined as follows:

"Method used to 'batch-read' from the persistent storage. It returns the
 NodeInfo for the given NodeId as the first element in the
 Iterator. In addition the iterator may contain arbitrary
 ItemInfos."

in other words: the SPI implementation is free to return any additional
iteminfos (even if not explicitly requested) and the 'client' (e.g. jcr2spi) is in charge of properly dealing with the information
returned... however, it's currently not possible for the 'client' to
pass multiple nodeIDs to the getItemInfo method.

the main reason for not having this in the SPI interface is - as you already stated - that there is not corresponding JCR API call for this.

We often have to need to load completely different nodes in the same
"request", with different structures and maybe even different nodetypes.
Currently, we have to get this all with many eg. Session.getNode(path)
requests. As we use davex to speak to Jackrabbit, this adds considerable
overhead, since we have to do a http request for each node.

What would be great now is if we could get all those nodes in one http
call. something like Session.getNodes(string[] path). I know it's not in
the specs, but is there a way to do something like that in the lower
levels of davex/http-remoting? If not, how hard would it be to implement
that and how should we do that?

if i properly understand you need, it would be sufficient for you in first step, if the server-side part of the jcr-remoting would be able to cope with a batch-read requests that asks for additional itemInfos
to be returned. is that correct?
without having thought about in detail i would guess that this should
be fairly easy: JcrRemotingServlet#doGet would need to be adjusted such
that not only processes the item at the requested url but respects
additional parameters passed...
the first step as usually would be to file an enhancement issue in jira.
even better if you have a patch (even if its only a draft).

And: Would Session.getNodes() be a good addition to the specs? Could be
useful for others as well.

that would rather be a question for the expert group of jsr333.
the corresponding issue tracker can be found at
http://java.net/jira/browse/JSR_333

hope that helps
angela

Reply via email to