10:00: JCR Intro (David)
11:00: JCR-333, CMIS, JCR Tips (David)
13:00: FLOW3/TYPO3 and JCR (Karsten)
14:00: Planning Symfony CMF 1.0
Vincent (symfony freelance)
Best of both worlds RDBMS+Filesystem
Key concept: Data first .. how does this relate to NoSQL? (David: search is not really needed)
JCP requires that a spec has a test suite (covering 90%+ of the sentences in the spec) reference implementation (which passes the tests 100%)
JCR didnt choose Java, but the JCP process
Jackrabbit is the bases for Day.com commercial products. Most backends use an RDBMS with only for scalable storage and transactions (not for example for referential integrity)
CMIS is a protocol (like HTTP) and JCR is an API, so they are complementary, not exclusive
Scripting language tweaks to the API
Internationalization improvements (aka things that are likely to be presented to a user, like the list of ACLs or the names of Workspaces)
JSOP: IETF standard (in discussion), sort of an evolution of Webdav. Standardization of the SPI protocol used between jackrabbit client and storage backend.
Jackrabbit 3.0 aims to be implemented as an Apache module eventually
JCR-333 is looking to add ability for the client to hint explicitly about the structure of the nodes (and subnode), like saying whenever I get node X, also give me all the subnodes (upto this level)
Started with JCR-170 but later moved to JCR-283 without support for any of the deprecated APIs
Eventually after a lot of infrastructure was built for TYPO3 5, it was decided to make it available as an independent framework without the CMS -> FLOW3
Separation between jackrabbit client and backend (spi) did not exist yet, using the PHP/Java bridge to connect to Jackrabbit was slow and error prone.
They started to implement their own full PHP implementation, persisted into relational database.
FLOW3 promotes Domain Driven Design and supports related concepts (entities, value objects, repositories) in it’s ORM (object relational manager). The FLOW3 persistence used the JCR as storage layer.
Problem with having ORM in the framework and a CMS on top of the framework: the CMS can not access storage (i.e. the JCR) directly, as it is hidden below the framework.
So we decided to use the framework persistence (default on sqlite) for the JCR which we moved above the framework into CMS implementation. But this means application knows about (some) infrastructure parts.
In the end it came down to throwing JCR out and building something of our own. JCR has lots of things TYPO3 doesn't need and at the same time was missing some things or doing them differently.
All that was started a while ago. We also could not use Doctrine2 because it was not yet ready. Now for you things might be different: Doctrine2 is usable but also Jackrabbit can be accessed from PHP without using the PHP/Java bridge.
Missing or not as wanted were:
JCR read layer to provide data may be an option eventually for TYPO3. But the implementation would build on top of FLOW3, not very suitable to build into Symfony.
Symfony CMF could do a “sparse” implementation of only what you really need for basic functionality.
what are we going to do?
tentative list of cmf features to implement for 1.0 (taken from liips internal planning)
symfony cologne maybe a next in-person meeting? lukas will promote this.
The goal is to have a beta version in sprint 2011.
liip is discussing to invest lots of man-days. other companies are invited to think about how much time they can invest.
phpcr repository basic implementation for the backend so applications can run without java on any cheap hosting. if somebody needs performance with lots of data or advanced features he should go with jackrabbit backend. for large installations there is dedicated hosting, plus solr is often used anyway, so java servers are not a blocker in that kind of project.
we should write a very simple php backend. later we can separate the backend and talk spi as jackrabbit does. to avoid splitting community we should state that the far future goal is having a performant full php backend. the question really is: does jcr / phpcr add much overhead compared to implementing those same features (node tree, revisions, access control, ...) directly inside the cmf? for sure it helps keeping the separation clean.
are there parts in jackalope that can be php-ified more (like the getValue() stuff with arrays or something?).
liip does recognize that it needs to take a leading role in the development of the storage backend due to the intimate know-how of JCR and jackalope. but as liip could live without a php backend, they will only invest time into that area if other members of the community contribute on the entire project.
Everybody reviews the notes
Lukas publishes notes
David emails list about scrum
Lukas checks if symfony day cologne could be used as the next in person meeting
Lukas brings up the tentative feature list on the list
Lukas explains to the list the current state of the Liip internal budget planning to encourage other companies to also detail their resource allocations