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 Only one workspace (Was: Handling namespace mapppings)
Date Fri, 30 Mar 2012 14:13:07 GMT
Hi,

On Fri, Mar 30, 2012 at 3:03 PM, Angela Schreiber <anchela@adobe.com> wrote:
> i am not asking for having synchronized copies. you got that wrong.

ACK, my mistake.

> well, here comes our disagreement. imo a session on oak-jcr would
> never see the complete repository as it is bound to a workspace.
> the information what is exposed by that workspace is the responsibility
> of oak-core and that's basically also the reason why i had the
> login-method that contained a workspace name.

I see your point. My main worry here is that without exposing the
entire repository tree (i.e. containing all workspaces plus the system
subtree) directly through the Oak API, we need to come up with a lot
of custom methods for handling cross-workspace operations that could
just as easily be expressed as content updates.

Anyway, to avoid getting stuck on this point, here's a somewhat
radical suggestion:

    Let's drop trying to support more than one workspace for now!

Practically all our use cases require just a single default workspace,
so we'll be able to cover most of our goals without worrying about
extra workspaces and the login/user management/jcr:system mapping/etc.
complexities they bring to the table.

Once we have the basics in place, we can return to the question of
workspace support say in the Oak 0.5 - 0.7 timescale (just a rough
estimate), at which point it should still be fairly straightforward to
implement.

WDYT?

BR,

Jukka Zitting

Mime
View raw message