Version 10

    How Shotoku compares and contrasts to JCR

     

    NOTE:  Shotoku and JCR are two completely different things.  This is really a contrast between JCR and Shotoku.  Shotoku can provide access to a JCR, or other types of repositories.

     

    Here is a short list of main differences:

    • The JCR API is much larger than Shotoku providing many more (and different) pieces of functionality than Shotoku.

    • Shotoku's primary repository implementation is SVN and those repositories are accessible via WebDAV, there is also a possibility to mount a directory as a local disk, or check it out as a working copy.  The JCR does not specify the transport mechanism to communicate with the repository but is an API and is designed to be a specification to interact with any repository where it is up to each implementation to define their method of communication (See jsr170-0.12 page 44: JCR on top of WebDAV)

    • Shotoku is designed to support clustering.  JCR doesn't discuss clustering at all.

    • Dependency injection via annotations - using JBoss AOP.  The JCR does not concern itself at all with AOP concepts.

     

    One of the biggest differences, and a distinct advantage of JCR, is the search mechanism - by executing queries. This isn't yet well planned in Shotoku, but we want to use SemanticWeb constructs to enhance the search capabilities.

     

    Another advantage the JCR cms implementations often have, is a web-based interface, through which files can be edited, uploaded, deleted etc. Shotoku doesn't have it, yet (!). It's on our road map :).

     

    What also has to be said, is that Shotoku can use JCR as its content repository.

     

    Finally, here is a short list of things that cause (or rather: will cause) Shotoku not to be a CMS only:

    • web components - blog and feeds. The latter can be already seen working on this site.

    • normally CMSs are used only for storing web pages that are shown to the user; Shotoku can be used (and is used in Labs) to store all site configuration: xml-s, navigation menu layout, jsp pages, etc.

    • it will also have event mechanisms informing about directories/ node changes. This can simplify a lot writing applications configurable via Shotoku.