[
https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994851#comment-15994851
]
Tomek Rękawek commented on OAK-6136:
------------------------------------
Hi [~rombert],
first of all - my apologies for not waiting for your vote. I thought that two
+1 is enough and didn't see you on IM to ask directly, but I should wait anyway.
bq. Federation to me see to be about different services becoming interoperable
More importantly I think it's about existing services that work in a standalone
fashion but can also work together - in a federated mode. \[...\] In our
scenario the mounts - those which we assemble - are not really usable by
themselves as they only contain a part of the repository.
In our case, the existing service is a node store and each of them has to be a
fully functional and working implementation. I think the [federated
MySQL|https://dev.mysql.com/doc/refman/5.7/en/federated-description.html]
engine is quite similar to what we have:
* Federated Table <-> mount list
* Remote Server <-> partial node store
* Remote Table <-> mounted subtree on the partial node store
bq. I think multiplexing is a better metaphor. It originally was about
combining multiple signals into a single one. I have no experience with
telecommunications so I won't comment on that but for me the concept of
combining multiple parts into a larger one is closer to what we offer with our
implementation.
I think that in case of multiplexing, each partial signal represents a value on
its own, is independent from the others and is not meant to be used together
with them. On the other hand, the multiplexed signal is just a noise and can't
be used directly. The only reason why it exists is that it's easy to transport
and store. Before using it, it has to be demultiplexed first - and as a result
we get the original, partial signals. So, the MultiplexingNodeStore name
suggest that we're providing a way to create a few independent node store
instances using the same underlying physical node store (which is an
interesting exercise as well and shouldn't be too hard, considering our data
model).
But our case it's the opposite - we want to use the combined store directly and
we don't care much how the data are persisted in the partial stores. That's why
I still think the "federated" is a better adjective here.
WDYT?
> Extract the multiplexing implementation code into a separate bundle
> -------------------------------------------------------------------
>
> Key: OAK-6136
> URL: https://issues.apache.org/jira/browse/OAK-6136
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: federated
> Reporter: Robert Munteanu
> Assignee: Julian Sedding
> Fix For: 1.7.0, 1.8
>
> Attachments:
> 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch,
> OAK-6136.patch
>
>
> Since we already kicked off the m12n effort for 1.8 it would be good to
> separate the multiplexing implementation from oak-core into its own bundle as
> well.
> I will look into providing a patch for the change.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
