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" <[email protected]> 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 <[email protected]>: > >>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" <[email protected]> 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 <[email protected]>: >>> >>>>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" <[email protected]> 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/> >>>> >>> >
