Hi Stefan, thanks for your reply.
Stefan Guggisberg schrieb:
hi daniel
-----Original Message----- From: Florey, Daniel [mailto:[EMAIL PROTECTED] Sent: Dienstag, 22. Juni 2004 23:49 To: Slide Developers Mailing List Subject: AW: demo of JSR 170 RI in proposals/jcrri
Hi Stefan!
The web frontend looks very sweet! Will this be donated under
Apache Licence?
there are no plans so far to donate the frontend, sorry.
:-(
Shall we open a thread as you stated here or is this list not the right place to discuss the spec as you stated later?I'd be interested in stealing the JavaScript code and the
graphics to get something comparable done using Slide/Projector.
Otherwise I have to paint some icons myself and that is something
we really should try to avoid ;-)
I'd like to discuss the JSR 170 with the community, but I still
haven't found the right place (mailinglist) for this. Should we
open a thread in the Slide mailinglist?
absolutely, i think that would be a good idea.
Please let me know, what is the right way/place to discuss the spec *in public*.
Thanks,
Daniel
Beside some minor issues (more a matter of taste), the main flaw
is IMO, that the API is not a 1:1 mapping of the well designed
WebDAV-protocols. As WebDAV is widley adopted, it should be
possible to address the full set of WebDAV features by using
JSR-170. And it should be possible, to access a JSR-170 based
content repository via WebDAV. Both is not possible with the
current revision of the JSR-170 API. Both is not possible with
the current revision of the JSR-170 API.
i disagree. JSR-170 supports a very granular content model (well-, semi- and unstructured) whereas WebDAV's content model is resource centric. i don't see why it shouldn't be possible to access JSR-170 implementations via WebDAV and WebDAV servers via JCR.
also, i suggest you direct your comments on the JSR-170 specification to mailto:[EMAIL PROTECTED], as this list is not the right place to discuss the spec.
i am not gonna delve further into the WebDAV vs. JSR-170 discussion as this has already been extensively discussed (including in this very list) and just repeating standpoints doesn't get us anywhere. i'd say let the community and the market decide.
So my advice would be, to shift the focus more towards the
WebDAV layer and build an API that simply maps WebDAV methods on
Java-methods.
If this would be the case, it would be possible to use Exchange,
IIS, Xythos, Slide, Apache, Subversion and all the other upcoming
WebDAV-servers with the JSR-170 API.
This would in first place mean, to drop the ticket stuff to
enable stateless server communication. If you take into account,
that the WebDAV-protocol is stateless, you'll run into trouble
when dealing with sessions/tickets on API level.
again, see above.
The JSR-170 is IMO not an API suitable for accessing existing
content repositories, but rather a new approach for designing a
content repository with a Java API.
have a look at the JSR-170 EG: http://www.jcp.org/en/jsr/detail?id=170 all major repository vendors have joined the expert group (ibm, vignette, oracle, documentum, filenet, ... to name just a few). most of them plan to support JSR-170 in their next product release. this should make you rethink your above statement...
There are many existing content repositories around, only a small
number is implemented in the Java language: Think of VCS's,
filesystems, databases and so on.
Will there be a JSR-170 implementation backed by CVS, Subversion,
Exchange and so on? I don't think so, as the API doesn't match well.
I'm sure that, if some discussions on the mailing list would take
place, we could find some really good solutions addressing the
different aspects of such an important API.
Perhaps we could combine this discussion with the discussion
regarding the design of Slide 3.0?
that would be a good starting point. regarding a possible archicture of integrating JSR-170 as suggested by remy maucherat maybe this is of interest. http://www.mail-archive.com/[EMAIL PROTECTED]/msg05538.html
Cheers!
Daniel
regards stefan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
