[Typo3-dev] JSR170

[Kasper Skårhøj]

Hi Daniel,

I'm currently reading on the JSR-170 specs (1443.0.jsr170-0.12.pdf).

Page 21-23 reveals to me that the standard can be implemented in three
ways:

- 1: We can offer this API for access of TYPO3 content
- 2: We can offer to access other JSR-170 repositories
- 3: We can offer to switch data model underneeth of TYPO3 and use
JSR-170 natively for storage.

Item 1: seems to be the use-cases most people expect to be the point.
This is easily possible for ANY developer you can find. There is no
integration with the core over the level of what Rene has done with
services. It could be achieved either as a backend or frontend feature,
most likely a backend one.

Item 2: Depends on what kind of integration is meant. If you want it
blended in with tables in the list module for instance, then the right
way to go is to write a driver in the DBAL layer for this. If you just
need an implementation that doesn't have to blend in with native
content, any backend module could do it. Again: Any developer could do
this.

Item 3: Natively using this standard? I don't think so. We would have to
rewrite TYPO3 completely and it would be another CMS. I'm sure this is
completely out of the question. BUT: If you really, really want: The
DBAL layer again could compensate for it! After all you could run TYPO3
from an Excel sheet with DBAL - but it is slow!


I'm all for allowing access to TYPO3's content via this standard. It has
not heavy cost for us to offer this, except write the gateway. But as
far as I'm concerned that is no different from offering an XML feed of a
table in TYPO3. It's just standardized and more advanced.




Reading from JSR-170:
- I'm sure it will be easy to map TYPO3s internal data structure to the
node/property paradigm of JSR-170 for reading.

Writing TYPO3 content via JSR-170:
- This will of course not be possible if you try to create nodes or
properties that is not possible with the table / field / flexform
structure inside of TYPO3. I don't know if JSR-170 expects to be able to
create any node/property it pleases, but that would be stupid.
- Having multiple parents for any node (record) is not possible in
TYPO3. There is always only one PID value per record. This cannot be
changed by any write action through JSR-170.


Compliance possibilities:
- I think Level 1 compliance is possible
	Retrieval and traversal of nodes and properties
	Reading and writing of the values of properties
	Creation of nodes and properties  [WITHIN the limits of TYPO3s data
structure of course! See above for comments.]
	Deletion of nodes and properties
	Assignment and discovery of node types [?]
	Searching the repository 

- Level 2 compliance could be possible in some cases:
	Transactions [The TYPO3 gateway to JSR-170 will have to simulate this
since the core doesn't have it and will probably not have it. A future
feature I call "Workspaces" might be a possibility, but they are meant
for something different.]
	Versioning [Yes, using the core versioning. Depends on support per
table of course. But this fits JSR-170's mention of " a workspace may
contain both versionable and nonversionable nodes"]
	Observation [?]
	Discovery of access permissions [Yes]
	Locking [We don't support this, but could consider creating support on
core level. Not a big deal.]




Before any of this could be implemented we would need:
- PHP support for JSR-170
- An external client that can be used to connect to and test the
interface in TYPO3.



-- 
- kasper

----------------
Man søger fred i rigdom, glans og ære
og tænker: Hvad kan hjertet mer begære?
men dybt derinde bor den samme længsel,
og hjertet græder i sit gyldne fængsel.