Hi,
Roy T. Fielding wrote:
I think it is a question of independence. AFAICT, the various gateways
under contrib are entirely dependent on the Jackrabbit project at the
moment and it would be very difficult for them to live independently.
JNDI, RMI, and webdav access seem to be very much in scope even when
they are coded to be independent of the JCR implementation, since
their purpose is to serve as deployment methods.
At the moment yes, as there are yet only a few real JCR implementations
out there, but what about later. The gateway components as well as the
underlying "commons" code is definitely useful for other projects as
well. Treating them as ordinary parts of the Jackrabbit implementation
will introduce troublesome partially-outside-the-project-scope
components within Jackrabbit. Of course this is also the current
situation, but at least we now have the contrib subdirectory keeping the
line... :-)
Another point to consider in drawing the scope line is the architectural
layering of the components. Many of these components in question live at
the opposite side of the JCR API layer, and thus considerably widen the
architectural scope of Jackrabbit.
+-------------------+
| RMI, Webdav, etc. |
+-------------------+
| JCR |
+-------------------+
| Jackrabbit |
+-------------------+
Both RMI and webdav are useful deployment mechanisms and, as such,
should be managed by the project and released as such for now.
Do you think that they are sustainable outside Jackrabbit? I mean,
do you think that Apache could eventually organize at least three
independent collaborators to run such a project outside of
Jackrabbit? I have a hard time believing that will ever be the
case, since interface layers tend to be one or two-person projects.
Not as separate projects perhaps, but I certainly see a need for a
common implementation-independent base of JCR components and tools. If
such a base should not be maintained within the Jackrabbit project, then
perhaps we should revisit the idea of a Commons-JCR project that was
briefly discussed during the last winter.
I think that a Commons project that would include for example RMI ja
Webdav layers and the recently added commons-chain commands in addition
to the general-purpose support code (ISO8601, Value handling, etc.) from
jackrabbit-commons could easily support a diverse-enough community for
the project to stand on it's own.
What's the general opinion about this?
I'm a bit worried about essentially renaming everything. Even if the
original component names perhaps aren't perfect, there's already quite
a lot of community buy-in, existing code, and mailing list references
to names like jcr-rmi and orm-persistence.
I don't buy this argument. There is no dependence on the existing
names, but there will be six months from now. We haven't made a
release yet and we are still in incubator, so I can't accept an
argument that there is a lot of buy-in from the community, and
the fact that it will become harder very soon should be motivation
to get the names right now. We need to imagine how people will
view the release and choose names according to the goal of helping
them understand. I want those names to be as clear as possible
before we spend a great deal of effort over the next few months
on documentation.
OK, you're probably right. Little pain now to avoid bigger pain later. I
can live with this. :-)
BR,
Jukka Zitting
