Agenda:

09:00: Welcome

10:00: JCR Intro (David)

11:00: JCR-333, CMIS, JCR Tips (David)

12:00: Lunch

13:00: FLOW3/TYPO3 and JCR (Karsten)

14:00: Planning Symfony CMF 1.0

17:00: End

Attendees:

Dan (Liip)

David (Liip)

Ebi (Liip)

Roland (Liip)

Chregu (Liip)

Vincent (symfony freelance)

Thibault (knpLabs)

Nils

Lukas (Liip)

Karsten

David (day.com)

Penny (Liip)

Late Arrivals:

Jordi (Liip)

Memi (Liip)

Philipp (Liip)

1st Presentation: JCR Introduction (David, day.com)

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)

2nd Presentation: JCR-333 and CMIS (David, day.com)

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.

JCR Tips: http://wiki.apache.org/jackrabbit/DavidsModel

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)

Karsten: TYPO3 5 and JCR

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.

Planning for symfony-cmf

what are we going to do?

tentative list of cmf features to implement for 1.0 (taken from liips internal planning)

basic architecture:

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.

Backend

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.

next steps:

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