1. The OBR is a federation, anybody can set up repos and any repo can
link to any number of other repos.
2. I like being able to restrict the scope of a search to "trusted"
parties.
3. Google has a significant delay before it discover resources, unless
you would be able to get them cooperate
4. I think Jeff McAffer raised a similar idea when we discussed OBR
in the beginning.
5. I think the OSGi is furthest ahead in metadata, which will make it
easier for things to work correctly. Notice that maven is not very
string in its dependency model.
Kind regards,
Peter Kriens
NH> On Monday 04 September 2006 14:59, Peter Kriens wrote:
>> Can this model be interesting for a new repository?
NH> I have not checked the details yet, but I am sure it is good work... ;o)
NH> Now, Raffael ain't that much into OSGi (yet), so his Ivy Reop is a lot
outside
NH> the OSGi world.
NH> In respect to the repository, I think the approach is generally not that
NH> great. I have stopped believing in central repositories. They don't scale
NH> well.
NH> Instead, I would like to see a repository model based on Google instead. For
NH> instance;
NH> * Each publisher has their own http server with the bundles in any format
NH> they wish.
NH> * Each publisher puts an "index file" on to that http server, and the index
NH> file contains a bunch of meta-info;
NH> - bundles available, bundle MD5 checksum, specs and categories those
NH> bundles belong to,
NH> - packages provided/required
NH> - services provided/required (optional)
NH> - public key signature of the publisher,
NH> - names, licensing, addresses and so forth,
NH> - A unique string, for instance
NH> G8o73408gfo2TOFGRH68tbhVoo2378etg8weou
NH> * The clients do a simple Google search for
NH> - the unique string and possibly
NH> - category and/or
NH> - specification identifiers and/or
NH> - publisher public key and/or
NH> - any other meta data stuck into it.
NH> The search result will hit on the index files which are downloaded and
NH> parsed.
NH> The clients can then implement features around security, caching,
directory
NH> and other things.
NH> IMHO, this allows repositories to scale, be responsive to new releases and
NH> control are transfered away from the repository owner to the publisher
NH> (what/when things are published) and consumer (what/who to trust)
NH> respectively.
NH> The whole concept could be easily be adapted for all Java jars, not only
OSGi,
NH> but let's take one thing at a time.
NH> Existing mega repositories, such as http://www.ibiblio.org/maven2 can easily
NH> be fitted with auto-generated index file.
NH> The Oscar Bundle Repository and possibly the OSGi Bundle Repository are
NH> probably already close to the above, they only need to stick in the Google
NH> friendly bits, and we can go off and write clients to do the real work. The
NH> difference is, I don't need anything from OSGi Alliance to publish my work.
NH> Cheers
NH> Niclas
NH> _______________________________________________
NH> general mailing list
NH> [email protected]
NH> http://lists.ops4j.org/mailman/listinfo/general
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
