Thanks for the feedback. I will comment in details after my morning shower,
but would like to shoot off a first impression.
I think, you and I attack the problem from different starting points, namely;
1. I start from the client use-case, and only worry about the API.
2. You start from the server requirement and a 'protocol' aspect.
Very similar to two people discussing JNDI vs LDAP.
As I said, I'll jump into the shower, get a coffee and then answer all your
question and send you my source files (later I run down and send in the CLA
to ASF ;o) ).
I think we can reach consensus fairly quickly, since I believe we are indeed
interested at different levels of the same problem.
Cheers
Niclas
On Sunday 09 November 2003 08:17, [EMAIL PROTECTED] wrote:
> > I had a look at the repository stuff in the sandbox, and perhaps I am not
> > capable of appreciating the effort to the full... :o(
> > My impression is that it is not very well abstracted and boiled down the
> > the
>
> Could you be more specific pointing to the classes/interfaces.
> I know it has a long way to go.
>
> > bare essentials from the "use-case" point of view, and I feel that it is
> > looking too much towards a foreign repository (Maven I presume).
>
> Yes it does look towards using a foreign repository that uses Maven's
> layout ATM ;).
>
> > First of all I have a very simple Resource defintion, extremely generic
> > at the moment. This is composed by the 4 interfaces below; ResourceInfo,
> > ReourceGroupInfo, Version and Compliance. (I am right now considering
> > generic Attributes on the resource as well, but have not put that in
> > yet.)
>
> Could you send me a copy of the interfaces?
>
> > 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.
>
> > 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?
>
> > // 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 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.
>
> > (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.
>
> > 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.
>
> > 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.
>
> > To me this design looks pretty solid and well abstracted, and it should
> > be possible;
>
> Perhaps if we take the time to point out the faults in the CVS code
> we can agree on a direction and march together.
>
> > 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.
>
> > 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.
>
> > "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 [EMAIL PROTECTED]
> 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.
>
> Alex
>
>
> ---------------------------------------------------------------------
> 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]
