Re: new name for the multiplexing node store
Likewise, the concept previously known as federated data store will now become CompositeDataStore. On Thu, May 11, 2017 at 7:27 AM, Tomek Rekawek wrote: > Hello, > > so, it seems we have the consensus. I’ll rename the implementation to > CompositeNodeStore and the module to oak-store-composite tomorrow afternoon. > > Regards, > Tomek > > -- > Tomek Rękawek | Adobe Research | www.adobe.com > reka...@adobe.com > > > On 11 May 2017, at 14:48, Julian Sedding wrote: > > > > +1 to CompositeNodeStore > > > > Regards > > Julian > > > > On Thu, May 11, 2017 at 10:36 AM, Bertrand Delacretaz > > wrote: > >> On Thu, May 11, 2017 at 9:33 AM, Robert Munteanu > wrote: > >>> ...MultiplexingNodeStore is a pretty standard implementation > >>> of the Composite design pattern... > >> > >> So CompositeNodeStore maybe? I like it. > >> > >> -Bertrand > >
Re: new name for the multiplexing node store
Hello, so, it seems we have the consensus. I’ll rename the implementation to CompositeNodeStore and the module to oak-store-composite tomorrow afternoon. Regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com reka...@adobe.com > On 11 May 2017, at 14:48, Julian Sedding wrote: > > +1 to CompositeNodeStore > > Regards > Julian > > On Thu, May 11, 2017 at 10:36 AM, Bertrand Delacretaz > wrote: >> On Thu, May 11, 2017 at 9:33 AM, Robert Munteanu wrote: >>> ...MultiplexingNodeStore is a pretty standard implementation >>> of the Composite design pattern... >> >> So CompositeNodeStore maybe? I like it. >> >> -Bertrand
Re: new name for the multiplexing node store
+1 to CompositeNodeStore Regards Julian On Thu, May 11, 2017 at 10:36 AM, Bertrand Delacretaz wrote: > On Thu, May 11, 2017 at 9:33 AM, Robert Munteanu wrote: >> ...MultiplexingNodeStore is a pretty standard implementation >> of the Composite design pattern... > > So CompositeNodeStore maybe? I like it. > > -Bertrand
Re: new name for the multiplexing node store
On Thu, May 11, 2017 at 9:33 AM, Robert Munteanu wrote: > ...MultiplexingNodeStore is a pretty standard implementation > of the Composite design pattern... So CompositeNodeStore maybe? I like it. -Bertrand
Re: new name for the multiplexing node store
Compositing, Aggregating, Unifying, Consolidating, Coalescing.
(Courtesy of an online thesaurus )
But I agree that the concept behind composition is the right one. All
in all, the MultiplexingNodeStore is a pretty standard implementation
of the Composite design pattern.
Robert
On Wed, 2017-05-10 at 13:20 +0200, Dominik Süß wrote:
> Naming discussions - love it (where is my popcorn? ;) )
>
> I would think that something with Compositing might be suitable as
> this is
> about composition of something that works as as final result but the
> artifacts might not be useful on their own.
>
> Cheers
> Dominik
>
> Am 05.05.2017 20:40 schrieb "Robert Munteanu" :
>
> Hi,
>
> On Fri, 2017-05-05 at 07:18 -0600, Matt Ryan wrote:
> > I was wondering about this also WRT federated data store. If the
> > intent
> > and effect of both are the same ("both" meaning what is currently
> > called
> > the "multiplexing node store" and the proposed (and in-progress)
> > "federated
> > data store"), it seems they should use a similar naming convention
> > at
> > least.
> >
> > WDYT? Does that make it more confusing or less confusing?
>
> I think the high-level intent is the same for both - compose a single
> {Data,Node}Store out of multiple sub-stores.
>
> The mechanisms might be different though, as the the NodeStore is
> hierarchical in nature, while the BlobStore blob ids are opaque.
>
> Also I still maintain :-) that federated blob stores will work well
> individually as they have no overall hierarchy to respect, while the
> multiplexed node stores will have to be composed to create a
> meaningful
> image.
>
> Robert
>
> >
> > -MR
> >
> > On Fri, May 5, 2017 at 6:10 AM, Julian Sedding
> > wrote:
> >
> > > Hi Tomek
> > >
> > > In all related discussions the term "mount" appears a lot. So why
> > > not
> > > Mounting NodeStore? The module could be "oak-store-mount".
> > >
> > > Regards
> > > Julian
> > >
> > >
> > > On Fri, May 5, 2017 at 1:39 PM, Tomek Rekawek
> > > wrote:
> > > > Hello oak-dev,
> > > >
> > > > the multiplexing node store has been recently extracted from
> > > > the
> > >
> > > oak-core into a separate module and I’ve used it as an
> > > opportunity
> > > to
> > > rename the thing. The name I suggested is Federated Node Store.
> > > Robert
> > > doesn’t agree it’s the right name, mostly because the “partial”
> > > node
> > > stores, creating the combined (multiplexing / federated) one, are
> > > not
> > > usable on their own and stores only a part of the overall
> > > repository
> > > content.
> > > >
> > > > Our arguments in their full lengths can be found in the OAK-
> > > > 6136
> > > > (last
> > >
> > > 3-4 comments), so there’s no need to repeat them here. We wanted
> > > to
> > > ask you
> > > for opinion about the name. We kind of agree that the
> > > “multiplexing” is not
> > > the best choice - can you suggest something else or maybe you
> > > think
> > > that
> > > “federated” is good enough?
> > > >
> > > > Thanks for the feedback.
> > > >
> > > > Regards,
> > > > Tomek
> > > >
> > > > --
> > > > Tomek Rękawek | Adobe Research | www.adobe.com
> > > > reka...@adobe.com
> > > >
Re: new name for the multiplexing node store
Naming discussions - love it (where is my popcorn? ;) )
I would think that something with Compositing might be suitable as this is
about composition of something that works as as final result but the
artifacts might not be useful on their own.
Cheers
Dominik
Am 05.05.2017 20:40 schrieb "Robert Munteanu" :
Hi,
On Fri, 2017-05-05 at 07:18 -0600, Matt Ryan wrote:
> I was wondering about this also WRT federated data store. If the
> intent
> and effect of both are the same ("both" meaning what is currently
> called
> the "multiplexing node store" and the proposed (and in-progress)
> "federated
> data store"), it seems they should use a similar naming convention at
> least.
>
> WDYT? Does that make it more confusing or less confusing?
I think the high-level intent is the same for both - compose a single
{Data,Node}Store out of multiple sub-stores.
The mechanisms might be different though, as the the NodeStore is
hierarchical in nature, while the BlobStore blob ids are opaque.
Also I still maintain :-) that federated blob stores will work well
individually as they have no overall hierarchy to respect, while the
multiplexed node stores will have to be composed to create a meaningful
image.
Robert
>
> -MR
>
> On Fri, May 5, 2017 at 6:10 AM, Julian Sedding
> wrote:
>
> > Hi Tomek
> >
> > In all related discussions the term "mount" appears a lot. So why
> > not
> > Mounting NodeStore? The module could be "oak-store-mount".
> >
> > Regards
> > Julian
> >
> >
> > On Fri, May 5, 2017 at 1:39 PM, Tomek Rekawek
> > wrote:
> > > Hello oak-dev,
> > >
> > > the multiplexing node store has been recently extracted from the
> >
> > oak-core into a separate module and I’ve used it as an opportunity
> > to
> > rename the thing. The name I suggested is Federated Node Store.
> > Robert
> > doesn’t agree it’s the right name, mostly because the “partial”
> > node
> > stores, creating the combined (multiplexing / federated) one, are
> > not
> > usable on their own and stores only a part of the overall
> > repository
> > content.
> > >
> > > Our arguments in their full lengths can be found in the OAK-6136
> > > (last
> >
> > 3-4 comments), so there’s no need to repeat them here. We wanted to
> > ask you
> > for opinion about the name. We kind of agree that the
> > “multiplexing” is not
> > the best choice - can you suggest something else or maybe you think
> > that
> > “federated” is good enough?
> > >
> > > Thanks for the feedback.
> > >
> > > Regards,
> > > Tomek
> > >
> > > --
> > > Tomek Rękawek | Adobe Research | www.adobe.com
> > > reka...@adobe.com
> > >
Re: new name for the multiplexing node store
Hello,
> On 5 May 2017, at 20:40, Robert Munteanu wrote:
>> I was wondering about this also WRT federated data store.
> I think the high-level intent is the same for both - compose a single
> {Data,Node}Store out of multiple sub-stores.
I also think that both implementations are conceptually similar and it’d be
good if the name can reflect this.
> The mechanisms might be different though, as the the NodeStore is
> hierarchical in nature, while the BlobStore blob ids are opaque.
>
> Also I still maintain :-) that federated blob stores will work well
> individually as they have no overall hierarchy to respect, while the
> multiplexed node stores will have to be composed to create a meaningful
> image.
The thing is that the multiplexed node store works on the node store level and
it doesn’t have any knowledge about JCR, trees, versioning, indexes, etc. - and
it’s the same for all the implementations. The only things it cares about are
node states and node builders. It’s true that the higher layers of Oak can use
this abstraction to model paths, JCR nodes, version histories, etc. - but for
the node store all of these things are hidden.
We’re creating a node store that takes a number of other stores and exposes
them together under the same interface - that’s why I think the federation is a
good name. Since we’re working the mechanism implemented on the node store
level, we should choose the name that makes sense for this level.
Please notice that the higher layers and the various Oak subsystems that has to
deal with the potential issues introduces by the multiplexing (eg. indexing or
permissions) doesn’t reference the MultiplexingNodeStore at all - they only use
the mounts. They don’t need to know what’s the node store implementation is,
because mount info provider gives them all the information they need. In fact,
sometimes it makes sense to configure the mounts with a simple Segment/Document
Node Store, not the multiplexing one.
Regards,
Tomek
--
Tomek Rękawek | Adobe Research | www.adobe.com
reka...@adobe.com
smime.p7s
Description: S/MIME cryptographic signature
Re: new name for the multiplexing node store
Hi,
On Fri, 2017-05-05 at 07:18 -0600, Matt Ryan wrote:
> I was wondering about this also WRT federated data store. If the
> intent
> and effect of both are the same ("both" meaning what is currently
> called
> the "multiplexing node store" and the proposed (and in-progress)
> "federated
> data store"), it seems they should use a similar naming convention at
> least.
>
> WDYT? Does that make it more confusing or less confusing?
I think the high-level intent is the same for both - compose a single
{Data,Node}Store out of multiple sub-stores.
The mechanisms might be different though, as the the NodeStore is
hierarchical in nature, while the BlobStore blob ids are opaque.
Also I still maintain :-) that federated blob stores will work well
individually as they have no overall hierarchy to respect, while the
multiplexed node stores will have to be composed to create a meaningful
image.
Robert
>
> -MR
>
> On Fri, May 5, 2017 at 6:10 AM, Julian Sedding
> wrote:
>
> > Hi Tomek
> >
> > In all related discussions the term "mount" appears a lot. So why
> > not
> > Mounting NodeStore? The module could be "oak-store-mount".
> >
> > Regards
> > Julian
> >
> >
> > On Fri, May 5, 2017 at 1:39 PM, Tomek Rekawek
> > wrote:
> > > Hello oak-dev,
> > >
> > > the multiplexing node store has been recently extracted from the
> >
> > oak-core into a separate module and I’ve used it as an opportunity
> > to
> > rename the thing. The name I suggested is Federated Node Store.
> > Robert
> > doesn’t agree it’s the right name, mostly because the “partial”
> > node
> > stores, creating the combined (multiplexing / federated) one, are
> > not
> > usable on their own and stores only a part of the overall
> > repository
> > content.
> > >
> > > Our arguments in their full lengths can be found in the OAK-6136
> > > (last
> >
> > 3-4 comments), so there’s no need to repeat them here. We wanted to
> > ask you
> > for opinion about the name. We kind of agree that the
> > “multiplexing” is not
> > the best choice - can you suggest something else or maybe you think
> > that
> > “federated” is good enough?
> > >
> > > Thanks for the feedback.
> > >
> > > Regards,
> > > Tomek
> > >
> > > --
> > > Tomek Rękawek | Adobe Research | www.adobe.com
> > > reka...@adobe.com
> > >
Re: new name for the multiplexing node store
I was wondering about this also WRT federated data store. If the intent
and effect of both are the same ("both" meaning what is currently called
the "multiplexing node store" and the proposed (and in-progress) "federated
data store"), it seems they should use a similar naming convention at least.
WDYT? Does that make it more confusing or less confusing?
-MR
On Fri, May 5, 2017 at 6:10 AM, Julian Sedding wrote:
> Hi Tomek
>
> In all related discussions the term "mount" appears a lot. So why not
> Mounting NodeStore? The module could be "oak-store-mount".
>
> Regards
> Julian
>
>
> On Fri, May 5, 2017 at 1:39 PM, Tomek Rekawek wrote:
> > Hello oak-dev,
> >
> > the multiplexing node store has been recently extracted from the
> oak-core into a separate module and I’ve used it as an opportunity to
> rename the thing. The name I suggested is Federated Node Store. Robert
> doesn’t agree it’s the right name, mostly because the “partial” node
> stores, creating the combined (multiplexing / federated) one, are not
> usable on their own and stores only a part of the overall repository
> content.
> >
> > Our arguments in their full lengths can be found in the OAK-6136 (last
> 3-4 comments), so there’s no need to repeat them here. We wanted to ask you
> for opinion about the name. We kind of agree that the “multiplexing” is not
> the best choice - can you suggest something else or maybe you think that
> “federated” is good enough?
> >
> > Thanks for the feedback.
> >
> > Regards,
> > Tomek
> >
> > --
> > Tomek Rękawek | Adobe Research | www.adobe.com
> > reka...@adobe.com
> >
>
Re: new name for the multiplexing node store
Hi Tomek In all related discussions the term "mount" appears a lot. So why not Mounting NodeStore? The module could be "oak-store-mount". Regards Julian On Fri, May 5, 2017 at 1:39 PM, Tomek Rekawek wrote: > Hello oak-dev, > > the multiplexing node store has been recently extracted from the oak-core > into a separate module and I’ve used it as an opportunity to rename the > thing. The name I suggested is Federated Node Store. Robert doesn’t agree > it’s the right name, mostly because the “partial” node stores, creating the > combined (multiplexing / federated) one, are not usable on their own and > stores only a part of the overall repository content. > > Our arguments in their full lengths can be found in the OAK-6136 (last 3-4 > comments), so there’s no need to repeat them here. We wanted to ask you for > opinion about the name. We kind of agree that the “multiplexing” is not the > best choice - can you suggest something else or maybe you think that > “federated” is good enough? > > Thanks for the feedback. > > Regards, > Tomek > > -- > Tomek Rękawek | Adobe Research | www.adobe.com > reka...@adobe.com >
new name for the multiplexing node store
Hello oak-dev, the multiplexing node store has been recently extracted from the oak-core into a separate module and I’ve used it as an opportunity to rename the thing. The name I suggested is Federated Node Store. Robert doesn’t agree it’s the right name, mostly because the “partial” node stores, creating the combined (multiplexing / federated) one, are not usable on their own and stores only a part of the overall repository content. Our arguments in their full lengths can be found in the OAK-6136 (last 3-4 comments), so there’s no need to repeat them here. We wanted to ask you for opinion about the name. We kind of agree that the “multiplexing” is not the best choice - can you suggest something else or maybe you think that “federated” is good enough? Thanks for the feedback. Regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com reka...@adobe.com smime.p7s Description: S/MIME cryptographic signature
