Hi, On Thursday, July 19, 2012, Thomas Mueller wrote: > > > Š oak-http are the > > only complex direct Java clients of the Oak API > > I thought Oak HTTP basically _is_ (very closely matches) the Oak API.
That's why I qualified it with "to a lesser degree", which you didn't include in your quote above. > On the other hand, we seem to have features (for example the transient > space) that were originally planned for the client now implemented in Oak > Core or even Oak MK (branch / merge). We should really discuss this. > > See the list archives from around March and April for extensive discussions about how the changelog of a transient space is best represented. The big point that people keep missing here is that we *need* a way to represent uncommitted changes inside oak-core, as otherwise things like node type validation or other commit hooks are impossible. A remoting client can and should still batch the transient space on the client side, the API design explicitly allows that. BR, Jukka Zitting Thomas > > > > > On 7/18/12 4:17 PM, "Jukka Zitting" <[email protected]<javascript:;>> > wrote: > > >Hi, > > > >On Tue, Jul 17, 2012 at 1:01 PM, Angela Schreiber > ><[email protected]<javascript:;> > > > >wrote: > >> not sure if it wise to expose such invisible content as "regular items" > >> on the oak-api. somehow it looks problematic to me that oak-jcr needs to > >> deal with internal stuff (and thus any other implementation of the > >>jcr-api > >> would need to do the same). > > > >Right, it's a trade-off between the size of the Oak API and complexity > >of clients. > > > >The reason why I instinctively prefer to keep the Oak API as tight and > >simple as possible is that we'll be needing various kinds of wrappers > >like remoting, caching, virtualization or logging layers around it. > >The smaller the API is, the easier it is to create and maintain such > >wrappers. And since oak-jcr and to a lesser degree oak-http are the > >only complex direct Java clients of the Oak API that we plan to > >support, pushing more functionality to above the Oak API to avoid > >complicating it is IMO often a reasonable tradeoff. > > > >> wasn't it a valid alternative to really keep the exact format of that > >> internal content as implementation detail in oak-core and rather expose > >> the information using specific methods on the oak-api/spi? > > > >In fact, the more I think of the specific case of the proposed > >":childOrder" property and orderability of nodes, the more it seems > >that you are right - it is better to hide these details below the Oak > >API and explicitly extend the API with an orderBefore() method like > >the one in JCR. The main reason why I think we need to do this is > >access control - otherwise oak-core would in any case need to > >"understand" the :childOrder property in order to properly filter out > >the names of any child nodes that the current client doesn't have read > >access to and thus shouldn't be aware of. > > > >> having a comprehensive list of the affected internal content might be > >> helpful in order to decide on how to deal with it. do you know how > >> many different internal items we are taking about? > > > >For now the only already existing cases are the :childOrder property > >needed by the orderability feature and the search index content that > >similarly needs to be hidden from clients of the Oak API for security > >reasons. Also in this case also the Oak API provides a mechanism for > >clients to properly access such internal content. > > > >Potential other cases of such internal content could be locking > >details not exposed by mix:lockable, automatic node metadata (last > >modified, content hash, etc.), or conflict markers. Without looking > >deeper into how to implement such features it's hard to say how they'd > >be best handled. > > > >BR, > > > >Jukka Zitting > -- Jukka Zitting
