jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: oak api : initial draft
Date Thu, 29 Mar 2012 09:00:46 GMT

> Assuming we merge SessionInfo and Connection together

for the time being i would like to keep it separated as
from my point of view the result of login to the repository
was something different than operating on the data
contained therein.

furthermore, having slept over the 'Connection' interface i am not
so confident any more that it's name really fits the purpose
that i was looking for... for me 'Connection' sounds very
vague. i am fine with that for the time being as we are still
very vague and just need something to get started. but i in the
long run this may need some refinement.

>>> in this case the session info was already bound to a given workspace
>>> and subsequently the Connection was bound to that workspace as well.
>> Yes that was my initial thinking too. That would mean the connections are
>> bound to a workspace. And workspaces (and workspace management) would have
>> to be exposed somehow through the oak API.

yes... somehow that was my idea as well. and i am not convinced
that mixing the repository-workspace concept on the oak-api was
the right way to go... currently this is more of a gut feeling
with some individual concerns popping up here and there.

> I'm a bit hesitant about this. It basically means that all
> cross-workspace operations will need custom API calls. If we make the
> login call per-repository and treat workspaces more or less just as a
> convention on the content structure, then oak-jcr can easily implement
> things like workspace management, etc. with no extra API or support
> from the oak-core level.

i am not sure if we can really easily implement things like workspace
management: for example creating a new workspace needs some initial
workspace setup (creating the root node, initial permissions, users) and 
i doubt that oak-jcr was the right place to do that.

> If the only reason why we need to expose the workspace concept at this
> level is to support potentially separate users per each workspace,
> then I'd rather handle that with a virtual repository mechanism that
> just connects to a separate underlying repository instance for each
> requested workspace.

well, didn't we decide at the last f2f that we are not going to
implement a virtual repository mechanism? for me that proposal
generates quite some question marks. having users being represented
as regular items in a given workspace feels very natural to me and
it has proven to fit our needs very well.

kind regards

View raw message