In search for a final name for oak-segment-next

[Michael Dürig <md...@apache.org>]

Hi,

The new oak-segment-next module [1] is in place. Now we need to decide 
on a final name [2]. Please use this thread to express ideas, 
suggestions and concerns. If necessary I'll cast a vote on a couple of 
candidates later.

My concerns are:
- Keep "segment" in the name. As it is sill very much what oak-segment 
was. The idea is to make it the replacement of oak-segment deprecating 
the latter.
- Choose a name that would fall in line with the names of future 
document node store implementations (should they live in their own modules).

Apart from this no real preferences only that sticking with 
oak-segment-next would mean the least amount of work for me ;-)

Michael

[1] https://issues.apache.org/jira/browse/OAK-4244
[2] https://issues.apache.org/jira/browse/OAK-4245

Re: In search for a final name for oak-segment-next

[Davide Giannella <da...@apache.org>]

On 22/04/2016 14:08, Francesco Mari wrote:
> As express offline, I would better choose a name that describes what the
> module does without leaking how the module works internally. My proposals
> are along the lines of "oak-local-store" and "oak-embedded-store". If
> having "segment" in the name is a major concern, I would opt for
> "oak-segment-store", as this name better describes what the module is
> supposed to be.

I like oak-segment-store if we want to express the "segment". If we want
to go on a more generic function oriented naming I prefer the
oak-embedded-store. The only caveat is that we, for any reason, come up
with another embedded store (which I don't think) to go along as option
with segment we could be in a small empass. Therefore I'd like
oak-segment-store.
>
> Since we are imagining the names of future NodeStore implementations, I
> find useless to have every first-level folder prefixed with "oak-". If I
> would lay out the project today, and assuming that our implementations
> would live in separate modules, I would opt for a structure like the
> following:
>
> /commons (oak-commons)
> /segment (oak-segment)
> /document/commons (oak-document-commons)
> /document/mongo (oak-document-mongo)
> /document/rdb (oak-document-rdb)
>
> Please note that I completely made up the names above to express my idea.

While I can agree on dropping the "oak" in first-level directories don't
really know if going for such restructure.

On both this and previous topic I don't have any strong opinions.

Davide

Re: In search for a final name for oak-segment-next

[Francesco Mari <ma...@gmail.com>]

As express offline, I would better choose a name that describes what the
module does without leaking how the module works internally. My proposals
are along the lines of "oak-local-store" and "oak-embedded-store". If
having "segment" in the name is a major concern, I would opt for
"oak-segment-store", as this name better describes what the module is
supposed to be.

Since we are imagining the names of future NodeStore implementations, I
find useless to have every first-level folder prefixed with "oak-". If I
would lay out the project today, and assuming that our implementations
would live in separate modules, I would opt for a structure like the
following:

/commons (oak-commons)
/segment (oak-segment)
/document/commons (oak-document-commons)
/document/mongo (oak-document-mongo)
/document/rdb (oak-document-rdb)

Please note that I completely made up the names above to express my idea.

2016-04-22 12:06 GMT+02:00 Michael Dürig <md...@apache.org>:

>
> Hi,
>
> The new oak-segment-next module [1] is in place. Now we need to decide on
> a final name [2]. Please use this thread to express ideas, suggestions and
> concerns. If necessary I'll cast a vote on a couple of candidates later.
>
> My concerns are:
> - Keep "segment" in the name. As it is sill very much what oak-segment
> was. The idea is to make it the replacement of oak-segment deprecating the
> latter.
> - Choose a name that would fall in line with the names of future document
> node store implementations (should they live in their own modules).
>
> Apart from this no real preferences only that sticking with
> oak-segment-next would mean the least amount of work for me ;-)
>
> Michael
>
> [1] https://issues.apache.org/jira/browse/OAK-4244
> [2] https://issues.apache.org/jira/browse/OAK-4245
>