Julian, I understand that you have efficiency related concerns. Fair enough. However, this is a discussion of the semantics of the spec, not implementation discussion. As well, this is the user list, I would assume that implementation discussions would belong in the dev mailing list...
Secondly, I know the original poster suggested only one way (update query results with transient state) but I've stated twice before that either that approach or just showing the persistent state (without ANY transient information) would be acceptable to me: "Maybe I'm totally missing the point, but I can't fathom *why* the spec would be written this way and really think it should just be one way or the other. ie. Either (ideally) respect the current session state and include ALL session changes in the query results, or, if that is somehow unacceptable/complicated/expensive operation etc., show me the persistent state - just not some funky combination!" Please note the *or* in the proposal that I gave, and read my full post for all the details. Best, Mark so far I haven't seen a proposal how the desired semantics (query
operating on the transient state) can be implemented efficiently at all, without closely coupling the transient space implementation to the storage. And, as a matter of fact, the contrary (de-coupling them) is what's currently being done in the Jackrabbit SPI work.
So, I'm not opposed to discuss this, but right now I just don't see how
to implement that. For the record, I'm fine with *allowing* repositories to implement that (but not making it required). Best regards, Julian
-- Best, Mark Waschkowski
