[ 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)