You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Ben Zahler <be...@inside-solutions.ch> on 2014/04/03 07:45:27 UTC
Oak Training: MikroKernels/NodeStores
Hi all,
after the last review feedback, I have revised the section on MicroKernels and NodeStores.
I would appreciate any feedback if this new version is both technically correct and also using the right terms.
The revised section is available here (User : review/Pwd: oak4502):
http://oak.inside-apps.com/Review_Microkernels_NodeStores.docx
Thanks in advance for any comments!
Regards,
Ben Zahler
Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
http://www.inside-solutions.ch<http://www.inside-solutions.ch/>
Re: Oak Training: MikroKernels/NodeStores
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
What I would like a training to have a detailed information about behavior
and usage differences between Jackrabbit 2.x and Jackrabbit Oak. I think
this would be very helpful. Roughly, this would be:
* JCR API behavior changes, for example "Item.save" is not supported and
falls back to "Session.save", or threads should not share sessions because
operations within a session are synchronized.
* Scalability gotchas, for example: observation listeners should only
listen for local events.
* Queries: switch from "blacklisting" to "whitelisting" (in Jackrabbit
2.x, the configuration was about what _not_ to index, and in Oak, the
configuration is about what to index).
Regards,
Thomas
On 10/04/14 08:27, "Ben Zahler" <be...@inside-solutions.ch> wrote:
>Thanks, Thomas, the term MongoDataStore was a mistake on my side (meant to
>write MongoDocumentStore).
>
>I will discuss the other points with Michael, who is responsible for the
>training on the Adobe side.
>
>
>Regards,
>Ben Zahler
>
>Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
>Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
>http://www.inside-solutions.ch <http://www.inside-solutions.ch/>
>
>
>
>
>
>Am 07.04.14 12:16 schrieb "Thomas Mueller" unter <mu...@adobe.com>:
>
>>Hi,
>>
>>>Since a CQ developer/architect must know the options for Oak
>>>architectures, I think the concepts of MikroKernel, NodeStore and
>>>DataStore must be part of the training. The actual APIs are not
>>>described
>>>in the training.
>>
>>Well, at the moment, the MicroKernel and the NodeStore are purely
>>internal
>>APIs. We might change (rename, whatever) those APIs without affecting the
>>users. That's why I would not document those. What is important and needs
>>to be documented is the Mongo storage, and the Tar storage. But I would
>>not use purely internal names, and specially I would not use the names
>>MikroKernel and NodeStore, because that already caused confusion in the
>>past.
>>
>>The DataStore API is less internal, I think it's OK to document it. Even
>>thought, it's also problematic. I would just document that there are
>>multiple way to store binaries: store them in the file system as separate
>>files, store them in the file system inside the Tar file (for the Tar
>>storage), store them in S3, store them in MongoDB. The DataStore API is
>>only used for two of those cases: separate files, and S3. The term
>>"MongoDataStore" doesn't exist in Oak (not even internally), so please
>>don't use it.
>>
>>Regards,
>>Thomas
>>
>>
>>
>>
>>
>>On 03/04/14 16:27, "Ben Zahler" <be...@inside-solutions.ch> wrote:
>>
>>>Hi Thomas,
>>>This is a AEM6 training that I am writing, so it¹s not exactly Oak
>>>documentation, and the delivery format is a word file.
>>>
>>>Of course if you feel that the documentation is helpful to the Oak
>>>project, it may make sense to add it to the oak-doc project.
>>>
>>>About your comments:
>>>Since a CQ developer/architect must know the options for Oak
>>>architectures, I think the concepts of MikroKernel, NodeStore and
>>>DataStore must be part of the training. The actual APIs are not
>>>described
>>>in the training.
>>>
>>>We describe MongoDB and the MongoDataStore in other sections of the
>>>training (complete training:
>>>http://oak.inside-apps.com/AEM6_OAK_Training_StudentWorkbook_v0-9-1.docx
>>>,
>>>review/oak4502). RDBMS was not described in deatil because afaik it is
>>>not
>>>yet officially supported as a storage in CQ (please correct me if I¹m
>>>wrong).
>>>
>>>Does that make sense for you?
>>>
>>>Regards,
>>>Ben Zahler
>>>
>>>Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
>>>Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
>>>http://www.inside-solutions.ch <http://www.inside-solutions.ch/>
>>>
>>>
>>>
>>>
>>>
>>>Am 03.04.14 11:45 schrieb "Thomas Mueller" unter <mu...@adobe.com>:
>>>
>>>>Hi,
>>>>
>>>>This is user documentation, right? We have a documentation project,
>>>>oak-doc, could you provide patches for that instead of writing
>>>>documentation in a Word file? I think that would be much more helpful.
>>>>Otherwise, your documentation will very quickly get ouf of date, unless
>>>>you spend a lot of time updating it. It's kind of the same as with copy
>>>>&
>>>>paste of source code: it's problematic because it increases mainteance,
>>>>as
>>>>well as the probability of bugs.
>>>>
>>>>As for documentation that is product specific, I would keep that
>>>>separate
>>>>and link to the relevant sections of the Oak documentation.
>>>>
>>>>So far, both the NodeStore and the MicroKernel APIs are internal APIs,
>>>>and
>>>>they don't affect the users of Oak. So I wouldn't mention them in user
>>>>documentation. If they are documented, that should be in internal
>>>>architecture and design documentation, meant for Oak developers, and
>>>>not
>>>>Oak users.
>>>>
>>>>What I would document is MongoDB storage, RDBMS storage, Tar file
>>>>storage.
>>>>The advantages / disadvantages, features and limitations, how to
>>>>configure
>>>>them, and so on.
>>>>
>>>>I would keep the documentation about the Document format, in the
>>>>MongoDB
>>>>storage section, because that's useful to analyze existing repositories
>>>>(to find problems, to get statistics, and so on). The details of that
>>>>data
>>>>model may change, but not that often, so I think it makes sense to
>>>>document it.
>>>>
>>>>Regards,
>>>>Thomas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>On 03/04/14 07:45, "Ben Zahler" <be...@inside-solutions.ch> wrote:
>>>>
>>>>>Hi all,
>>>>>after the last review feedback, I have revised the section on
>>>>>MicroKernels and NodeStores.
>>>>>
>>>>>I would appreciate any feedback if this new version is both
>>>>>technically
>>>>>correct and also using the right terms.
>>>>>
>>>>>The revised section is available here (User : review/Pwd: oak4502):
>>>>>http://oak.inside-apps.com/Review_Microkernels_NodeStores.docx
>>>>>
>>>>>Thanks in advance for any comments!
>>>>>
>>>>>Regards,
>>>>>Ben Zahler
>>>>>
>>>>>Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
>>>>>Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
>>>>>http://www.inside-solutions.ch<http://www.inside-solutions.ch/>
>>>>
>>>
>
Re: Oak Training: MikroKernels/NodeStores
Posted by Ben Zahler <be...@inside-solutions.ch>.
Thanks, Thomas, the term MongoDataStore was a mistake on my side (meant to
write MongoDocumentStore).
I will discuss the other points with Michael, who is responsible for the
training on the Adobe side.
Regards,
Ben Zahler
Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
http://www.inside-solutions.ch <http://www.inside-solutions.ch/>
Am 07.04.14 12:16 schrieb "Thomas Mueller" unter <mu...@adobe.com>:
>Hi,
>
>>Since a CQ developer/architect must know the options for Oak
>>architectures, I think the concepts of MikroKernel, NodeStore and
>>DataStore must be part of the training. The actual APIs are not described
>>in the training.
>
>Well, at the moment, the MicroKernel and the NodeStore are purely internal
>APIs. We might change (rename, whatever) those APIs without affecting the
>users. That's why I would not document those. What is important and needs
>to be documented is the Mongo storage, and the Tar storage. But I would
>not use purely internal names, and specially I would not use the names
>MikroKernel and NodeStore, because that already caused confusion in the
>past.
>
>The DataStore API is less internal, I think it's OK to document it. Even
>thought, it's also problematic. I would just document that there are
>multiple way to store binaries: store them in the file system as separate
>files, store them in the file system inside the Tar file (for the Tar
>storage), store them in S3, store them in MongoDB. The DataStore API is
>only used for two of those cases: separate files, and S3. The term
>"MongoDataStore" doesn't exist in Oak (not even internally), so please
>don't use it.
>
>Regards,
>Thomas
>
>
>
>
>
>On 03/04/14 16:27, "Ben Zahler" <be...@inside-solutions.ch> wrote:
>
>>Hi Thomas,
>>This is a AEM6 training that I am writing, so it¹s not exactly Oak
>>documentation, and the delivery format is a word file.
>>
>>Of course if you feel that the documentation is helpful to the Oak
>>project, it may make sense to add it to the oak-doc project.
>>
>>About your comments:
>>Since a CQ developer/architect must know the options for Oak
>>architectures, I think the concepts of MikroKernel, NodeStore and
>>DataStore must be part of the training. The actual APIs are not described
>>in the training.
>>
>>We describe MongoDB and the MongoDataStore in other sections of the
>>training (complete training:
>>http://oak.inside-apps.com/AEM6_OAK_Training_StudentWorkbook_v0-9-1.docx
>>,
>>review/oak4502). RDBMS was not described in deatil because afaik it is
>>not
>>yet officially supported as a storage in CQ (please correct me if I¹m
>>wrong).
>>
>>Does that make sense for you?
>>
>>Regards,
>>Ben Zahler
>>
>>Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
>>Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
>>http://www.inside-solutions.ch <http://www.inside-solutions.ch/>
>>
>>
>>
>>
>>
>>Am 03.04.14 11:45 schrieb "Thomas Mueller" unter <mu...@adobe.com>:
>>
>>>Hi,
>>>
>>>This is user documentation, right? We have a documentation project,
>>>oak-doc, could you provide patches for that instead of writing
>>>documentation in a Word file? I think that would be much more helpful.
>>>Otherwise, your documentation will very quickly get ouf of date, unless
>>>you spend a lot of time updating it. It's kind of the same as with copy
>>>&
>>>paste of source code: it's problematic because it increases mainteance,
>>>as
>>>well as the probability of bugs.
>>>
>>>As for documentation that is product specific, I would keep that
>>>separate
>>>and link to the relevant sections of the Oak documentation.
>>>
>>>So far, both the NodeStore and the MicroKernel APIs are internal APIs,
>>>and
>>>they don't affect the users of Oak. So I wouldn't mention them in user
>>>documentation. If they are documented, that should be in internal
>>>architecture and design documentation, meant for Oak developers, and not
>>>Oak users.
>>>
>>>What I would document is MongoDB storage, RDBMS storage, Tar file
>>>storage.
>>>The advantages / disadvantages, features and limitations, how to
>>>configure
>>>them, and so on.
>>>
>>>I would keep the documentation about the Document format, in the MongoDB
>>>storage section, because that's useful to analyze existing repositories
>>>(to find problems, to get statistics, and so on). The details of that
>>>data
>>>model may change, but not that often, so I think it makes sense to
>>>document it.
>>>
>>>Regards,
>>>Thomas
>>>
>>>
>>>
>>>
>>>
>>>On 03/04/14 07:45, "Ben Zahler" <be...@inside-solutions.ch> wrote:
>>>
>>>>Hi all,
>>>>after the last review feedback, I have revised the section on
>>>>MicroKernels and NodeStores.
>>>>
>>>>I would appreciate any feedback if this new version is both technically
>>>>correct and also using the right terms.
>>>>
>>>>The revised section is available here (User : review/Pwd: oak4502):
>>>>http://oak.inside-apps.com/Review_Microkernels_NodeStores.docx
>>>>
>>>>Thanks in advance for any comments!
>>>>
>>>>Regards,
>>>>Ben Zahler
>>>>
>>>>Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
>>>>Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
>>>>http://www.inside-solutions.ch<http://www.inside-solutions.ch/>
>>>
>>
Re: Oak Training: MikroKernels/NodeStores
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>Since a CQ developer/architect must know the options for Oak
>architectures, I think the concepts of MikroKernel, NodeStore and
>DataStore must be part of the training. The actual APIs are not described
>in the training.
Well, at the moment, the MicroKernel and the NodeStore are purely internal
APIs. We might change (rename, whatever) those APIs without affecting the
users. That's why I would not document those. What is important and needs
to be documented is the Mongo storage, and the Tar storage. But I would
not use purely internal names, and specially I would not use the names
MikroKernel and NodeStore, because that already caused confusion in the
past.
The DataStore API is less internal, I think it's OK to document it. Even
thought, it's also problematic. I would just document that there are
multiple way to store binaries: store them in the file system as separate
files, store them in the file system inside the Tar file (for the Tar
storage), store them in S3, store them in MongoDB. The DataStore API is
only used for two of those cases: separate files, and S3. The term
"MongoDataStore" doesn't exist in Oak (not even internally), so please
don't use it.
Regards,
Thomas
On 03/04/14 16:27, "Ben Zahler" <be...@inside-solutions.ch> wrote:
>Hi Thomas,
>This is a AEM6 training that I am writing, so it¹s not exactly Oak
>documentation, and the delivery format is a word file.
>
>Of course if you feel that the documentation is helpful to the Oak
>project, it may make sense to add it to the oak-doc project.
>
>About your comments:
>Since a CQ developer/architect must know the options for Oak
>architectures, I think the concepts of MikroKernel, NodeStore and
>DataStore must be part of the training. The actual APIs are not described
>in the training.
>
>We describe MongoDB and the MongoDataStore in other sections of the
>training (complete training:
>http://oak.inside-apps.com/AEM6_OAK_Training_StudentWorkbook_v0-9-1.docx ,
>review/oak4502). RDBMS was not described in deatil because afaik it is not
>yet officially supported as a storage in CQ (please correct me if I¹m
>wrong).
>
>Does that make sense for you?
>
>Regards,
>Ben Zahler
>
>Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
>Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
>http://www.inside-solutions.ch <http://www.inside-solutions.ch/>
>
>
>
>
>
>Am 03.04.14 11:45 schrieb "Thomas Mueller" unter <mu...@adobe.com>:
>
>>Hi,
>>
>>This is user documentation, right? We have a documentation project,
>>oak-doc, could you provide patches for that instead of writing
>>documentation in a Word file? I think that would be much more helpful.
>>Otherwise, your documentation will very quickly get ouf of date, unless
>>you spend a lot of time updating it. It's kind of the same as with copy &
>>paste of source code: it's problematic because it increases mainteance,
>>as
>>well as the probability of bugs.
>>
>>As for documentation that is product specific, I would keep that separate
>>and link to the relevant sections of the Oak documentation.
>>
>>So far, both the NodeStore and the MicroKernel APIs are internal APIs,
>>and
>>they don't affect the users of Oak. So I wouldn't mention them in user
>>documentation. If they are documented, that should be in internal
>>architecture and design documentation, meant for Oak developers, and not
>>Oak users.
>>
>>What I would document is MongoDB storage, RDBMS storage, Tar file
>>storage.
>>The advantages / disadvantages, features and limitations, how to
>>configure
>>them, and so on.
>>
>>I would keep the documentation about the Document format, in the MongoDB
>>storage section, because that's useful to analyze existing repositories
>>(to find problems, to get statistics, and so on). The details of that
>>data
>>model may change, but not that often, so I think it makes sense to
>>document it.
>>
>>Regards,
>>Thomas
>>
>>
>>
>>
>>
>>On 03/04/14 07:45, "Ben Zahler" <be...@inside-solutions.ch> wrote:
>>
>>>Hi all,
>>>after the last review feedback, I have revised the section on
>>>MicroKernels and NodeStores.
>>>
>>>I would appreciate any feedback if this new version is both technically
>>>correct and also using the right terms.
>>>
>>>The revised section is available here (User : review/Pwd: oak4502):
>>>http://oak.inside-apps.com/Review_Microkernels_NodeStores.docx
>>>
>>>Thanks in advance for any comments!
>>>
>>>Regards,
>>>Ben Zahler
>>>
>>>Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
>>>Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
>>>http://www.inside-solutions.ch<http://www.inside-solutions.ch/>
>>
>
Re: Oak Training: MikroKernels/NodeStores
Posted by Ben Zahler <be...@inside-solutions.ch>.
Hi Thomas,
This is a AEM6 training that I am writing, so it¹s not exactly Oak
documentation, and the delivery format is a word file.
Of course if you feel that the documentation is helpful to the Oak
project, it may make sense to add it to the oak-doc project.
About your comments:
Since a CQ developer/architect must know the options for Oak
architectures, I think the concepts of MikroKernel, NodeStore and
DataStore must be part of the training. The actual APIs are not described
in the training.
We describe MongoDB and the MongoDataStore in other sections of the
training (complete training:
http://oak.inside-apps.com/AEM6_OAK_Training_StudentWorkbook_v0-9-1.docx ,
review/oak4502). RDBMS was not described in deatil because afaik it is not
yet officially supported as a storage in CQ (please correct me if I¹m
wrong).
Does that make sense for you?
Regards,
Ben Zahler
Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
http://www.inside-solutions.ch <http://www.inside-solutions.ch/>
Am 03.04.14 11:45 schrieb "Thomas Mueller" unter <mu...@adobe.com>:
>Hi,
>
>This is user documentation, right? We have a documentation project,
>oak-doc, could you provide patches for that instead of writing
>documentation in a Word file? I think that would be much more helpful.
>Otherwise, your documentation will very quickly get ouf of date, unless
>you spend a lot of time updating it. It's kind of the same as with copy &
>paste of source code: it's problematic because it increases mainteance, as
>well as the probability of bugs.
>
>As for documentation that is product specific, I would keep that separate
>and link to the relevant sections of the Oak documentation.
>
>So far, both the NodeStore and the MicroKernel APIs are internal APIs, and
>they don't affect the users of Oak. So I wouldn't mention them in user
>documentation. If they are documented, that should be in internal
>architecture and design documentation, meant for Oak developers, and not
>Oak users.
>
>What I would document is MongoDB storage, RDBMS storage, Tar file storage.
>The advantages / disadvantages, features and limitations, how to configure
>them, and so on.
>
>I would keep the documentation about the Document format, in the MongoDB
>storage section, because that's useful to analyze existing repositories
>(to find problems, to get statistics, and so on). The details of that data
>model may change, but not that often, so I think it makes sense to
>document it.
>
>Regards,
>Thomas
>
>
>
>
>
>On 03/04/14 07:45, "Ben Zahler" <be...@inside-solutions.ch> wrote:
>
>>Hi all,
>>after the last review feedback, I have revised the section on
>>MicroKernels and NodeStores.
>>
>>I would appreciate any feedback if this new version is both technically
>>correct and also using the right terms.
>>
>>The revised section is available here (User : review/Pwd: oak4502):
>>http://oak.inside-apps.com/Review_Microkernels_NodeStores.docx
>>
>>Thanks in advance for any comments!
>>
>>Regards,
>>Ben Zahler
>>
>>Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
>>Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
>>http://www.inside-solutions.ch<http://www.inside-solutions.ch/>
>
Re: Oak Training: MikroKernels/NodeStores
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
This is user documentation, right? We have a documentation project,
oak-doc, could you provide patches for that instead of writing
documentation in a Word file? I think that would be much more helpful.
Otherwise, your documentation will very quickly get ouf of date, unless
you spend a lot of time updating it. It's kind of the same as with copy &
paste of source code: it's problematic because it increases mainteance, as
well as the probability of bugs.
As for documentation that is product specific, I would keep that separate
and link to the relevant sections of the Oak documentation.
So far, both the NodeStore and the MicroKernel APIs are internal APIs, and
they don't affect the users of Oak. So I wouldn't mention them in user
documentation. If they are documented, that should be in internal
architecture and design documentation, meant for Oak developers, and not
Oak users.
What I would document is MongoDB storage, RDBMS storage, Tar file storage.
The advantages / disadvantages, features and limitations, how to configure
them, and so on.
I would keep the documentation about the Document format, in the MongoDB
storage section, because that's useful to analyze existing repositories
(to find problems, to get statistics, and so on). The details of that data
model may change, but not that often, so I think it makes sense to
document it.
Regards,
Thomas
On 03/04/14 07:45, "Ben Zahler" <be...@inside-solutions.ch> wrote:
>Hi all,
>after the last review feedback, I have revised the section on
>MicroKernels and NodeStores.
>
>I would appreciate any feedback if this new version is both technically
>correct and also using the right terms.
>
>The revised section is available here (User : review/Pwd: oak4502):
>http://oak.inside-apps.com/Review_Microkernels_NodeStores.docx
>
>Thanks in advance for any comments!
>
>Regards,
>Ben Zahler
>
>Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz
>Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
>http://www.inside-solutions.ch<http://www.inside-solutions.ch/>