avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Eclipse Plug-in
Date Sun, 09 Nov 2003 02:14:38 GMT
On Sunday 09 November 2003 08:17, aok123@bellsouth.net wrote:
> Could you be more specific pointing to the classes/interfaces.

Maybe later. As I said, I looked at it, didn't understand it well, and had 
problem to see how to use it.

One thing; I don't like specs that has classes (other than Exceptions and 
EventObjects).

> > I then have a RepositoryAgent interface, which knows how to communicate
> > with a particular repository type, to retrieve the resource metainfo and
> > the resource itself. One RepositoryAgent instance per actual repository.
>
> Actually the Repository really is an agent that works on behalf of
> the user.  The Repository does not represent the remote repository
> but the functional unit that interfaces with it.  I would tend to
> agree with you on the Agent notion here it fits.
>
> > Since the RepositoryAgent can be of different types (such as Maven,
> > Niclas, Alex, HyperDuper, etc) I need a factory class for each
> > RepositoryAgent type, simply called RepositoryAgentFactory.
>
> Right the RepositoryFactory/Repository is synonymous I think.

Good. My reason being that Repository should be kept for a server 
specification of building a repository (not that I really think we should).


> > The RepositoryAgentFactory is registered with the RepositoryTypeRegistry.
> > For each URN type, the implementation registers (somehow) with the
> > RepositoryTypeRegistry (now an interface, and would need to get
> > instantiated as well somehow).
> > A repository has (from my POV) the form like;
> >
> >    urn:[type]:[location]
> >
> > for instance,
> >    urn:plain-url:file:///opt/avalon/repository/
> >
> > To use this, as client, you do
> >
> > String urn = urn:plain-url:file:///opt/avalon/repository/;
> > RepositoryTypeRegistry reg = ... // Some way to find the registry.
> > RepositoryAgentFactory factory = reg.getRepositoryAgentFactory( urn );
> > RepositoryAgent agent = factory.create( urn );
>
> I'm embarrassed to admit that I have never used this urn concept before.
> What other [type] fields exist?

Anything. My work does not really concentrate on the [type] field, as that is 
basically implementations of different repository types. I.e. you will create 
a MavenRepositoryAgentImpl (and its factory), and then somehow (also not part 
of the spec) register "maven" with the RepositoryTypeRegistry. In some code, 
somewhere it could look like (observe the conditional sentence);

RepositoryAgentFactory mavenFactory = new MavenRepositoryAgentFactory();
RepositoryTypeRegistry registry = .... // get reference to registry.
registry.registerRepositoryAgentFactory( "maven", mavenFactory );

and then a

urn:maven:http://www.ibiblio.com/apache/avalon/component/repository

or something would work.

Sounds good?

The PlainURLRepositoryAgent(Factory) is my own reference implementation to 
show that the API works.

> > // load root resource group ("").
> > ResourceInfo[] infos = agent.loadResourceInfo( "" );
> >
> > for( int i=0 ; i < infos.length ; i++ )
> > {
> > 	String name = infos[i].getName();
> > 	String descr = infos[i].getDescription();
> >
> > 	InputStream in = agent.openInputStream( infos[i] );
> >
> > }
>
> You're going to need a repo with a database for this.  Pulling all this
> info as artifacts from a large repo like the ibiblio one could be a massive
> undertaking taking on the order of seconds to pull every descriptor
> artifcat.  Just thinking to myself here.  

I now realize that I should probably change the signature of 
ResourceInfo[] loadResourceInfo( String resourceGroup );
to plain
ResourceGroup loadResourceGroup( String resourceGroup );

It doesn't change the principal.
The point in place is that the ResourceInfo object is fairly small, and 
repositories should be structured to some degree to avoid naming conflicts 
(maybe they are not now, but if there were browsers around, I think that 
would change quickly).
The method call only returns the container that is requested in each call, not 
the entire tree under. The implementation is free to do any kind of clever 
pre-fetching, caching and so on under the hood.

Have you ever used the CVS browser in Eclipse or Netbeans??
If not, do so. Point it to :pserver:anoncvs@cvs.apache.org:/home/cvspublic (a 
fairly large CVS) and you will be surprised how snappy it is. Because, under 
the hood, it retrieves what is need now + one layer below what can be seen, 
so when you open a folder it is instantenous.
I expect a professional RepositoryAgent(Factory) implementation to be 
operating in the same manner.


> I don't know if you're privy to
> it but I'm very bent towards enabling the conventional (maven) repo with
> a queriable interface.  This way we can ask complex questions about the
> artifacts (Resources) contained therein.

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.

> > (It is arguable if the openInputStream() should be within the
> > ResourceInfo instead, but I think that by putting it in the agent, the
> > ResourceInfo implementation can possibly be very generic, and not
> > re-implemented for each repository type.)
>
> Right keep the content access mechanism separate from the data.
> ResourceInfo sounds like a simple bean to me analogous to the
> ArtifactDescriptor bean in the sandbox now.

Exactly what I was thinking.

> > ResourceGroup is an interesting concept, that I have promoted to first
> > class citizens over the day. It is a type of Resource that can contains
> > other Resources. That means that
> > "MyComponent" is a ResourceGroup, where as
> > "MyComponent Ver 1.0.0" is a "leaf" Resource.
>
> Awesome you're getting into resource composition and heirarchy is
> creeping into the picture.  I like the resource nesting principal
> by association using groups.  It may be a logical resourse (artifact)
> rather than a physical one and the containment can nest indefiniately.

At first, it was just an optional presentation feature, but it became tricky 
to provide all the visual attributes (Name, Description), and it looked so 
natural to introduce it as a first class citizen.

> > One could possibly even imagine that
> > "MyComponent-1.0.0.jar" is a ResourceGroup containing other resources
> > internally.
> > And I can also categorize my resources in any imaginable way.
>
> Right but you want to avoid the jar in a jar concept.  If you model
> you grouping based on a physical mechanism then you limit yourself
> to particular artifact types that support physical containment.

Yes, again, this is implementation specific, and not part of my thought train 
at the moment. The model is purely abstract, and have no clue of the physical 
properties, and the "user" doesn't need to know.

> > Also, I have introduced listeners on RepositoryTypeRegistry,
> > RepositoryAgentFactory and RepositoryAgent, which are notified about any
> > changes loaded or detected. This will drive a UI, for instance, very
> > well.
>
> Like the way infobus works I guess.  But the RespositoryAgent also needs
> to get notification from the remote repository no?  You can do this with
> LDAP asynchronous notifaction if a LDAP/Http based repo was built for the
> relational/content access respectively.

Again, that is a "under the hood" feature. An LDAPRepositoryAgentImpl may have 
all kinds of funky stuff going on under the hood.
Point here is, by making the Event Model part of the speciication, 
asynchronous events under the hood, will indeed update the GUI accordingly. 
Also, it is necessary to make the GUI snappy, i.e. instead of reading the 
data when the user click somewhere, you initialize the operation and return, 
then the event will come later and update the UI.

> > What do you think?
>
> I generally tend to agree with you but I don't think we're that far
> off in our points of view.  I think getting to a common ground is
> very easy if we commit the time and patience to it.  We'll be better
> off considering the other POV for it and we always need someone or
> two to bounce ideas off of who are intimate with the code.

YES, I think so too. I wish I could consume other people's effort as easily as 
you have shown here. Maybe if you could provide me with a use-case of how the 
code in CVS is to be used, it would clear any fog in my brain.

> > "This doesn't belong in Avalon!"  -  Yes, this has struck me too, but
> > let's iron it out here before we decide what to do with it.
>
> Yes I think the entire ASF is discussing that on the repository@apache.org
> list at the present moment including the folks on the incubator list.  It's
> a horizontal concept that is relavent across several projects and I think
> it should be centralized for the entire ASF somewhere.  Then we can build
> on it for our needs however I feel very strongly about makeing the remote
> repository a directory for relational queries as well as a webserver for
> artifact content download.

I don't follow that discussion, but I assume that they are very "server" and 
"protocol" focused. That is fine, and doesn't interfere with my PoV, just 
like JNDI and LDAP are orthogonal (starting to sound like Stefano... :o(  ).

I send the source separately, but not until after the change above, and tidy 
it up a little bit. Expect an hour or two.

Cheers,
Niclas

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


Mime
View raw message