My main problem with SPI is that if I return depth=1 results from getItemInfos (a NodeInfo for each subfolder), JCR2SPI ends up subsequently calling getChildInfos anyway, to find out what ALL the children are, regardless of the fact that I just returned what all the children are in my GetItemInfos response.
>From JCR2SPI's point of view, the problem seems to be that it had no way of >knowing whether I returned SOME, or ALL, of the subfolders. In that sense, >it's the Iterator return value types that I have a problem with. I would >prefer returning a container, that could encapsulate the Iterator, but also >allow for declaring formalized hints, and maybe even out-of-band data that >JCR2SPI chooses to look at as hints. And the hint JCR2SPI needs from getItemInfos is "response includes all children" (or "this response contains depth=1 results"). It would also not hurt for depth=0 results to be able to return the equivalent of IMAP's \HasChildren flag. Because in that case, getItemInfos could return depth=0 results, and then in the case where there are no children, JCR2SPI could avoid the unnecessary getChildInfos when there are no results. David -----Original Message----- From: Marcel Reutegger [mailto:[EMAIL PROTECTED] Sent: Thu 2/7/2008 3:49 PM To: [email protected] Subject: Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session Julian Reschke wrote: > I think I understand batch read, and how JCR2SPI would use that. What I > don't see how it helps in this case. > > An SPI implementation *could* return ItemInfos for all children when the > NodeInfo for a collection is fetched, but how would it know that anybody > wants to see the members? Angela and I discussed this some time ago and we decided that for now we leave to up to the implementation. basically for simplicity. See also javadoc RepositoryService.getItemInfos(). Visit Synchronica at GSMA Mobile World Congress, Barcelona, 11-14 Feb, Hall 2, Booth #2J25
