On Friday 07 November 2003 17:04, Berin Loritsch wrote:
The solution I propose would allow and foster the creation of several component repositories, but provide one index so that folks know where to look for components that they may want to use.
An index is not a repository. People can look up an index, interpret the content, move on to N locations, interpret the "local language", figure out which component can do what is needed, find the download area, and manually insert them into a development effort.
How about a tool doing this?? Not that easy...
That is what I was getting at.
Most of the hard work has been done. Look at the Web Services architecture. They have WSDL to identify the interface of the web service, so that we can look up compatible implementations. They have an index service (can't remember the acronym right now) that provides a way to find the servers hosting the component, and any meta-info that would help make a decision for it.
And the fact that an index is not a repository was the exact point I wanted to make. I think having a one size fits all repository is destined to fail. Having an index to support the infrastructure of finding components that would be needed from multiple repositories would allow for several repositories that are *focused* on a particular problem space. That would facilitate islands of expertise which can be leveraged.
What the index needs is a way to identify the interface of the components so that we can find what will work with our system. Next we need to have a bunch of meta-info to allow for human intervention with the decision process. All our interaction would be with the index, so the index itself would take care of downloading (or proxying the request) for the component itself. Since we are not *hosting* any of the components, but merely providing a lookup service, we can have LGPL or GPL implementations mixed with our ASL implementations.
The major thing is that the interface has to be packaged separately and licensed under the ASL or compatible license. Our contract is with the license, and our code that uses the components would be using the interface directly--not the implementation. The way our containers work, each component is essentially isolated as much as possible from each other.
We start with the simple part--which is providing a lookup service for components based on their interface. We can probably use the Manifest entries that identify interface as the lookup key, and expand as necessary.
We would need to look at options for "self management". Have it all hosted as an Avalon project using Merlin to run the index server, and it would really rock.
It also means we don't have to answer the question of one contract for all Avalon components. We have the containers the component was designed to be compatible with, and filter out all the containers that won't work for our project.
Of course we would seed it with our components, but I believe that this would be the best way to get the message out there that we are serious about making Avalon a force to be reconed with--and we don't have to ram it down anyone's throat to do that.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
