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.
What about an solution which covers both, workspace bound connections
and repository bound connections? In such a setup you'd get a workspace
bound connection from the RepositoryService and you could get a
Repository bound connection from the a given Connection. The latter
could then be used for cross workspace operations.
Michael
