On Thu, 1 Mar 2001, Geir Magnusson Jr. wrote:
> David Weinrich wrote:
>
> >
> > As far as I understand it, this project is very similar to the 'commons'
> > on a university campus ( sometimes called the quad or whatever else sounds
> > good ). It is a place where the members of the university share common
> > services like a library, usually a bookstore, etc... that don't fit into
> > the purpose of the colleges/departments that make up the university. In
> > the same way this project is more service-based than product-based.
>
> I disagree with the analogy because I think something important is
> getting left out. The productized-component-initiative is in this model
> another department - the DBConnectionPool is just as valuable a
> standalone project to software developers as ORO and Regexp is. It
> would be a project in it's own right, with committers, docs, users, etc.
>
> Now, I recognize that having these small components as independant
> entitites in Jakarat as peers to Tomcat, Struts, etc, wouldn't scale
> well, hence the notion of library or catalog - a place where these could
> be [independantly!] productized.
>
> >[SNIP]
> > Jakarta Commons ( hey let's throw yet another name on the pile ;) Project
> >
> > Agora Service:
> >
> > * As described before a 'sandbox' where people from different
> > projects can come together and work on taking common code
> > and forming it into something that can be shared.
>
> +1 : but it too is a project, I think, with open access to all Jakarta
> committers, etc
>
> > Catalog Service ( I've been tempted to propose calling this 'Dewey'
> > after the old card catalog/subject numbering system
> > subjected on many of us in earlier years ):
> >
> > * A way for end users to look up the products present in the library
> > and in the jakarta projects. ( Ted can give a more detailed
> > description of this :)
>
> +1 -> this is what I was talking about in the first msg of this thread
> as a 'Directory' not a catalog, as I thought of the catalog as a place
> for 'ready for sale' components (I think you call it Library Service
> below), but I agree with the idea, and so sick of tracking all the
> names, it doesn't matter to me what it is called.
I agree, the names do get confusing after a while ;) See below for more...
>
> > Library Service:
> >
> > * A place for matured 'products' ( quite possibly developed in the
> > Agora service ) to be stored for use/reuse by end users. Much of
> > what makes up the library service provides is based upon the
> > other two services, what really makes the difference is the
> > standards set for inclusion of the products in the library as
> > seperate products ( documentation, testing, support ).
>
> +1 -> I hate the name :) But the important thing, I think, is that the
> Library Service is just a shell - each product within is it's own
> project like any other jakarta project. It is responsible for it's docs
> separately from the other products, etc ,etc ,etc. Now, forcing
> documentation and other standards would be great, but the idea of them
> being little projects in their own right is important [to me].
>
Right, each product in the library will have it's own set of
documentation/webpages/maintainers and will exist in the library. I see a
contrast between this and the 'Directory/Catalog' as the difference
between a set of books, and the searchable description/card catalog that
people use to find the right book(s).
> > The goal shared by this project and the services it holds is the to
> > facilitate sharing code that is common both internally within jakarta and
> > the projects it holds and externally in the end products built with the
> > products of jakarta by users.
>
> No. I like the sentiment, but seems too complicated. If you just said
> that 'Commons' mission is a Jakarta project to be a container / home for
> small/misc projects that support the Jakarta mission, I think it would
> work out the same way.
If you insert the word services somewhere, I think that is pretty damn
close. Hell that sentence even confused me when I read it again, sorry for
the wording and structure :).
> Then Agora is a project, Catalog is a project,
> and I think you can eliminate the library service idea, since each
> entity in the Library service is a completely self-supporting project in
> it's own right, so it might as well be a peer to Agora and Catalog, just
> to keep people from having to dig too far to find things. In a diagram
> :
if you say it as 'Agora is a service, Catalog is a service, and Library is
a place to put the actual components' it makes more sense. The catalog is
mostly a reference to what is where ( I hope, Ted is this close? ). Agora
is a common area for different projects to come together and find a way to
turn the code inside their projects into a common tool ( or even propose a
new tool if no implementation exists ). The library is where the tools get
put, once they have reached a point where the API and the code is stable
and the documentation/support structure for that component is worked out
and meets some kind of standards.
>
> Jakarta
> |
> | -> Tomtcat
> | -> Commons
> | |
> | |->Agora
> | |->Catalog
> | |-> DBConnectionPool
> | |-> XMLCOnfig
> |
> | -> Turbine
> etc
Ok I'll take a stab at this too :)
Jakarta
|
| -> Tomtcat
| -> Commons
| |
| |->Agora
| | |-> A collection of projects in the process of creating
| | components, with people collaborating from different
| | jakarta projects.
| |
| |->Catalog
| | |-> Searchable links to what is available where.
| |
| |->Library
| | |
| | |-> DBConnectionPool
| | |-> XMLCOnfig
| | |-> A set of reusable components that have reached a stable
| point in their lifecycle and meet standards for support
| infrastructure and documentation.
|
| -> Turbine
Hopefully this is a bit more clear compared to my somewhat confuzzled
writing.
>
> > A side effect of this goal/project
> > combination is it gives the jakarta committers a place to do this type of
> > work and experimentation without having a detrimental effect to the
> > projects they are working on. Hope this helps, and if I'm way off base
> > anyone can fix up this description how they see fit.
>
> This is true in two ways :
>
> 1) Agora gives them a place to muck around
> 2) Catalog provideds visibility for useful packages and components w/o
> the added work of removing from a project codebase and supporting
> outside of the project as well as removing any documentation requirement
> that might come about when code is pushed out of a project.
>
> geir
>
>
> --
> Geir Magnusson Jr. [EMAIL PROTECTED]
> Developing for the web? See http://jakarta.apache.org/velocity/
>
