cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@cocoon.apache.org
Subject [Cocoon Wiki] Updated: GT2003HackathonJsr170
Date Thu, 20 May 2004 13:45:46 GMT
   Date: 2004-05-20T06:45:46
   Editor: 212.254.251.89 <>
   Wiki: Cocoon Wiki
   Page: GT2003HackathonJsr170
   URL: http://wiki.apache.org/cocoon/GT2003HackathonJsr170

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -1,68 +1,71 @@
-=  David Nuscheler on JSR 170 =
-[http://www.jcp.org/en/jsr/detail?id=170 JSR 170] - Content Repository for JavaTM technology
API
-
-David is from [http://www.day.com Day software]
-==  Overview ==
-Problem: over 800 CMS vendors, currently each with their own 
-Solution: API. JSR 170 aims to standardize access to content repositories.
-
-JSR 170 is an API, compared to WebDAV which is a protocol.
-
-It sits between something like WebDAV and an actual repository.
-
-Even though big players who could have conflicting interests were involved in the design
of JSR 170, it seems like the API is clean, well designed and everybody agrees on it.
-
-JSR 170 is entering the community review phase, an Open-Source reference implementation is
in the works.
-
-Apache members have access to the JCP "papers" but not committers.
-
-Contains simple query language.
-
-Workflow and lifecycle management (auto archiving etc). are seen as an applications, not
as being part of the repository.
-==  Roadmap ==
- *  Community review is imminent, should be done by the end of 2003
- *  Reference implementation (from Day IIUC?) with Open-Source-friendly and patent-(un)friendly
license (designed to avoid people patenting parts of the implementation).
-==  Levels of compliance ==
-Similar in concept to the JDBC compliance levels.
-===  Level 1: everything you need for Presentation and Publishing ===
-Basic compliance level for storage (vendors of repositories).
-  * Read and write access to the content
-  * Hierarchy operations - hierarchical storage space like a filesystem, familiar
-  * Serialization/deserialization - mapping repo structure to ??
-  * Node Type - how does this node work, what is it's meta data?
-    * no difference between data and meta-data, they are handled in the same way, not seen
as "different animals"
-  * Search/Filter
-    * a SQL-like query language, comes with the API
-    ** based on SQL syntax, with extensions
-    ** geared more towards hierarchies
-  * Linking
-
-According to David, Level 1 contains everything you need for presentation and publishing.
-===  Level 2: versioning, transactions, locking (a superset of Level 1) ===
-  * Versioning (David warns that you might need a brain transplant first to understand this
part of the spec)
-    * works with linking
-    * Still needs TLC
-  * Transactions (distributed, XA)
-  * Observation (Events, similar to DB Triggers etc.) (optional part of the Interface)
-    * Synchronous/Asynchronous events. Synchronous events are vetoable.
-    * eg. will be very powerful for Cocoon, repo can tell Cocoon Cache about changes
-    * eg. will make currently uncachable sources, cachable
-
-  * Locking
-==  Questions/remarks ==
- *  Gianugo asks about connecting a level 1 client to a level 2 repository: will versions
be created automatically?
-  * Hard to answer, it will be up to the repository to implement implicit versioning or not.
-  * Problem could be, server creates a new version for each save operation
-=== Reference Implementation (proposal inside Slide) ===
-Most of Level 1 (without searching, they will use Lucene for this)
-=== How to move forward? ===
-
-Slide never made it off the ground. (Stefano : It was 2 seperate one-man-shows )
-XIndice does not evolve.
-
-Create a new community for this (in Cocoon?) where people care about this?
-
-Question: What about Lenya?
-Stefano: IMO Lenya is working slightly the wrong way, mixing back and front end (, ie. mixing
User and Editor view)
-
-We should stop at the API.
+=  David Nuscheler on JSR 170 =
+[http://www.jcp.org/en/jsr/detail?id=170 JSR 170] - Content Repository for JavaTM technology
API
+
+David is from [http://www.day.com Day software]
+==  Overview ==
+Problem: over 800 CMS vendors, currently each with their own 
+Solution: API. JSR 170 aims to standardize access to content repositories.
+
+JSR 170 is an API, compared to WebDAV which is a protocol.
+
+It sits between something like WebDAV and an actual repository.
+
+Even though big players who could have conflicting interests were involved in the design
of JSR 170, it seems like the API is clean, well designed and everybody agrees on it.
+
+JSR 170 is entering the community review phase, an Open-Source reference implementation is
in the works.
+
+Apache members have access to the JCP "papers" but not committers.
+
+Contains simple query language.
+
+Workflow and lifecycle management (auto archiving etc). are seen as an applications, not
as being part of the repository.
+==  Roadmap ==
+ *  Community review is imminent, should be done by the end of 2003
+ *  Reference implementation (from Day IIUC?) with Open-Source-friendly and patent-(un)friendly
license (designed to avoid people patenting parts of the implementation).
+==  Levels of compliance ==
+Similar in concept to the JDBC compliance levels.
+===  Level 1: everything you need for Presentation and Publishing ===
+Basic compliance level for storage (vendors of repositories).
+  * Read and write access to the content
+  * Hierarchy operations - hierarchical storage space like a filesystem, familiar
+  * Serialization/deserialization - mapping repo structure to ??
+  * Node Type - how does this node work, what is it's meta data?
+    * no difference between data and meta-data, they are handled in the same way, not seen
as "different animals"
+  * Search/Filter
+    * a SQL-like query language, comes with the API
+    ** based on SQL syntax, with extensions
+    ** geared more towards hierarchies
+  * Linking
+
+According to David, Level 1 contains everything you need for presentation and publishing.
+===  Level 2: versioning, transactions, locking (a superset of Level 1) ===
+  * Versioning (David warns that you might need a brain transplant first to understand this
part of the spec)
+    * works with linking
+    * Still needs TLC
+  * Transactions (distributed, XA)
+  * Observation (Events, similar to DB Triggers etc.) (optional part of the Interface)
+    * Synchronous/Asynchronous events. Synchronous events are vetoable.
+    * eg. will be very powerful for Cocoon, repo can tell Cocoon Cache about changes
+    * eg. will make currently uncachable sources, cachable
+
+  * Locking
+==  Questions/remarks ==
+ *  Gianugo asks about connecting a level 1 client to a level 2 repository: will versions
be created automatically?
+  * Hard to answer, it will be up to the repository to implement implicit versioning or not.
+  * Problem could be, server creates a new version for each save operation
+=== Reference Implementation (proposal inside Slide) ===
+Most of Level 1 (without searching, they will use Lucene for this)
+=== How to move forward? ===
+
+Slide never made it off the ground. (Stefano : It was 2 seperate one-man-shows )
+XIndice does not evolve.
+
+Create a new community for this (in Cocoon?) where people care about this?
+
+Question: What about Lenya?
+Stefano: IMO Lenya is working slightly the wrong way, mixing back and front end (, ie. mixing
User and Editor view)
+
+We should stop at the API.
+----
+For further information:
+now in public review [http://jcp.org/aboutJava/communityprocess/review/jsr170/index.html]

Mime
View raw message