avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: Eclipse Plug-in
Date Sun, 09 Nov 2003 06:17:38 GMT
> > > > OK, this is a VERY good point. But any Query language or system
> > > > typically requires a lot of thought to be powerful, yet reasonably
> easy
> > > > to implement. Let us discuss that later/separately.
> > > (& (objectClass=block) (service=o.a.a.DataStore) (version>1.0)
> > > (| (container=Merlin) (container=Phoenix) ) )
> >
> > I would like to see you implement that for any type of repository, CVS
> for
> > instance?

> Maybe I wasn't clear enough.

I think I did not make sense either.  Let me start from scratch by saying 
you define your API to ask the database questions.  No query passing
here.  Just things like list groups, give me all the dependencies.  Or
give me all the attributes associated with an artifact.  This is the 
database interface but it does not have methods that take a filter or
query.  For example I might have a method getAllDependencies().  This may
translate in the implementation into the execution of a query to find
this information yet we do not pass in the query.

The implementation under the hood talks to a database to query it
for these attributes.  The database that best fits the job here IMHO
is a directory and LDAP is what I'm thinking.  This is a very repo
specific API.

Another approach could be to use an existing and generic access 
interface like JNDI.  You could design a special JNDI provider for the
repository and use that for your access model.  Then if you felt like it
you can support directory interfaces conduct searchs using any kind of
filters you devise.  So this is yet another approach to build an interface 
around a repository directory with meta data.

> For a Query system to work, it is important that;
> 1. There is a solid user API contract, preferably easy to use.
> 2. The query implementation for each repository type is reasonably easy to
> implement.
> 3. The implementation could pass the query, full or in part, to the
> server, to
> lower network activity.

> So, what I am saying, the Query discussion will continue beyond my first
> use-case, i.e. it is a separate use-case and handled accordingly.

Ok with me.  I have a couple of things that I'm trying to manage now too
with the spi, api, impl split in the repository.


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message