jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Internal content in Oak
Date Thu, 19 Jul 2012 08:37:40 GMT

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.


Jukka Zitting

> On 7/18/12 4:17 PM, "Jukka Zitting" <jukka.zitting@gmail.com<javascript:;>>
> wrote:
> >Hi,
> >
> >On Tue, Jul 17, 2012 at 1:01 PM, Angela Schreiber <anchela@adobe.com<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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message