Sent by travis wissink on 21 November 2003 13:01
I believe that this JSR is trying to over simplify the needs of a CMS API.
Maybe similar to other vendor specific JSR's like JSR 143 and its over
simplification of write once run everywhere fully manageable fat clients.
There is a lot more to a good CMS vendor's API than just versioning and
locking checks. An API really needs the vendors value offering incorporated
into its own API; because we all know each product has different value
propositions. However, perhaps more important is the real value to us the
users and implementers of these CMS's. I would purpose a more finely tuned
requirement for a CMS JSR.
What I would like to see out of a CMS JSR is a nice clean java API that
interfaces with any type of content repository. This API should allow users
access to production available content. Both, Weblogic and Websphere have
this concept built into their personalization API's, I am more familiar with
Weblogic's. Weblogic has a document service providers interface, the
"Document manager." This API allows me, a weblogic developer, to request
content from a content repository, through a vendor neutral interface and
vendor neutral query language. Many of the vendors, IWOV, Fatwire,
Documentum, Stellant, etc... have built a "Document manager" for BEA's
personalization product. Now what I believe would be nice is if, on the
coat tails of JSR 168's success, the vendors could produce one driver, i.e.
similar to JDBC, to interact with production capable content from their
blackbox content repositories (regardless of the products native language).
In essence, providing developers with the ability to create a write one
query to execute against any type of content repository. This interface
shouldn't just be limited to CMS vendors but also other software markets as
well, such as querying into ecommerce product catalogs and trouble ticketing
systems knowledge bases.
The subsequent architecture to this JSR would be the framework to "plug"
these drivers together so that developers could execute one query and
receive a consolidated result set from all content repositories. I think
that this would provide much value back to all of our customers and not just
Communiqué's customers.
-Travis
----- Original Message -----
From: "Serge Huber" [EMAIL-REMOVED]>
To: [EMAIL-REMOVED]>
Sent: Friday, November 21, 2003 6:14 AM
Subject: Fwd: Re: [cms-list] JSR170?
Oops this was supposed to go to the list. Why isn't the list configured so
that the reply automatically goes to the list ? All the other lists I'm on
do this !
Regards,
Serge Huber.
>Date: Fri, 21 Nov 2003 12:13:22 +0100
>To: Rickard Öberg [EMAIL-REMOVED]>
>From: Serge Huber [EMAIL-REMOVED]>
>Subject: Re: [cms-list] JSR170?
>
>
>Well one of the arguments I could see for JSR 170 support on small systems
>would be to be able to move content from one Java CMS to another,
>achieving "portability" of CMS :)
>
>Anyway, my thoughts on JSR 170 is that although it is a good thing, it is
>too limited. I think there should be some sort of language-agnostic
>binding, such as JSR-168 has WSRP, so that people can access CMS content
>even outside of Java applications. Granted you could always build your own
>wrappers, but it wouldn't be standard.
>
>CMS systems often assume that you will use them, and that's it. But this
>does not reflect the reality of what's going on in small, medium and large
>enterprises. Systems have to interconnect, and CMS' especially should on
>the long term be able to help people use their data on different mediums.
>It's a pipe dream but why not ?
>
>So in effect my reflections on JSR-170 it's similar to JDBC. It's a common
>interface to talk to Java-based CMS', so it'll do some good, but it will
>not necessarily be the overwhelming standard (what happens if Microsoft
>starts defining a SOAP standard for example ?)
>
>Regards,
> Serge Huber.
>
>At 08:16 AM 11/21/2003, you wrote:
>>Hi!
>>
>>I work for a Java CMS vendor, and we are considering implementing JSR 170
>>(Java Content Repository). If any of the other vendors are interested,
>>I'd like to discuss the merit of this JSR, and when/why one would
implement it.
>>
>>In the spec itself they describe a situation where a large
>>company/organization have many content repositories (CR), which they want
>>to be able to access for various reasons. In this case JCR would be a
>>good API for doing so.
>>
>>However, are there any reason for a CMS vendor with mostly smaller
>>organizations to implement it? If there is only one CMS in place, and
>>typically that is the case for smaller, or even medium organizations,
>>what are the possible use-cases for it?
>>
>>Here are some ideas I can see:
>>* Writing portlets (JSR168) that access and present content using only
>>standard API's.
>>* Generating reports that the CMS itself does not provide.
>>* Inserting content from another backend source, like a database.
>>etc.
>>
>>If possible, I would like to know how other vendors view this JSR, and
>>it'd also be great to know what end-users(/admins) think of it.
>>
>>regards,
>> Rickard, a Java CMS vendor
>>
>>--
>>http://cms-list.org/
>>please trim your posts.
>
>- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
>www.jahia.org : A collaborative source CMS and Portal Server
- -- --- -----=[ shuber2 at jahia dot com ]=---- --- -- -
www.jahia.org : A collaborative source CMS and Portal Server
--
http://cms-list.org/
please trim your posts.
--
http://cms-list.org/
please trim your posts.