Berin, BTW I think the ws index/service/directory is UDDI.
> > From: Berin Loritsch <[EMAIL PROTECTED]> > Date: 2003/11/12 Wed AM 05:26:45 EST > To: Avalon Developers List <[EMAIL PROTECTED]> > Subject: Re: [Counter PROPOSAL] Avalon Component Index > > Niclas Hedhman wrote: > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
