|
note that we are currently in the process of separating the phpcr interfaces from the jackalope implementation to make it more obvious what is the standard. https://github.com/jackalope/phpcr What would be the most logical first step? Presumably we would want to include the source and auto-generated docs in the package just as we now include the java source and javadoc. But in terms of adapting the spec itself, would it be sufficient to include a new section containing, essentially, the information in https://github.com/phpcr/phpcr/blob/master/doc/JCR_TO_PHPCR.txt Yes, I think this would be a sensible approach. Provide the interfaces with source and auto-generated docs. And explain the differences and common conversions from the Java-interfaces in a chapter in the specs. I guess it would be good, if we document all changes in the doc, but I guess it doesn't end up in much more than is already in the JCR_TO_PHPCR.txt doc yes, JCR_TO_PHPCR is more or less complete. there was some stuff added to the phpcr api later, but i think its debatable if it makes any sense to have that there (we could also make it impl specific) what really needs a good final decision is binary handling. we half-use the BinaryInterface and should decide what we really want (with respect to performance and future proof). The PHPCR code has been added to svn, and the PHPCR section has been added to the spec. |
||||||||||||||||||||||||||||||||||||||||||
The popular Symfony PHP framework is using PHPCR for their CMF initiative: http://cmf.symfony.com/

To ease development we have also created an ODM (object document model) layer using the popular Doctrine2 (sort of a Hibernate for PHP): https://github.com/doctrine/phpcr-odm
In other words there is considerable commitment behind PHPCR already. The goal is to formalize this especially to ensure that different implementations like Jackalope and Midgard will play nicely with eachother, but also to ensure that PHPCR and JCR stay compatible.
In a second step we might also want to look at adding some things into JCR that scripting languages in general would appreciate (for example native support for associative arrays).