Re: [Aperture-devel] OSGI

[Antoni M. <Ant...@df...>]

Christiaan Fluit napisa=C5=82(a):
> What I see here is a proposal for organizing stuff in bundles but what=20
> is lacking IMHO is a rationale for why you draw the lines there. If I=20
> understand you correctly, all Aperture APIs and related stuff would go=20
> into a single bundle, right? But what does a MimeTypeIdentifier API hav=
e=20
> to do with a Crawler API, except that they are both part of the Apertur=
e=20
> project? Why not put them into their own bundles?

1. Let's assume we do as you write:
a. we still need a core bundle with RDFContainer (used by all),=20
Vocabulary (At least DATA), DataSource, Utils, security etc.
b. around this one, we would need seven 'hub' bundles that would contain=20
two or three classes and expose registries:
 >> DataAccessorRegistry
 >> CrawlerRegistry
 >> DataSourceRegistry
 >> ExtractorRegistry
 >> LinkExtractorRegistry
 >> MimeTypeIdentifierRegistry
 >> DataOpenerRegistry

c. around every 'hub' bundle we'd need a set of implementation bundles.=20
Some of them would depend only on core and the appropriate 'hub' but=20
some (like the FileSystemCrawler) would depend on the core and ALL=20
(maybe except dataOpener registry). The Dependency graph would look like=20
spaghetti.

Now let's assume we want to write a FileSystemCrawler and implement it=20
as a separate bundle. I will be much more complicated than it is now,=20
because it won't be able to assume that AccessorRegistries and Extractor=20
Registries are available. It will have to handle cases when an Extractor=20
Registry becomes unavailable in the middle of crawling. It would need to=20
implement at least two ServiceTrackers and handle arbitrary interactions=20
between services appearing and disappearing. An application that would=20
like to use two or three elements of aperture (that is Accessor and=20
Extractor, or a Crawler that uses Accessors or Extractors) would need to=20
be sure that all of these are present.

It would be much easier for all to be able to assume that all registries=20
are present at all times. (or not :-) Writing crawlers that use=20
Accessors, Extractors or LinkExtractors would be much easier. The=20
management of dependencies would be easier.

> Just one more argument for fine-grained bundles ;) : each bundle can=20
> have its own private classpath. This makes it possible to e.g. create a=
n=20
> extractor for a specific MIME type that contains all its third party=20
> dependencies, without necessarily exposing those dependencies to the=20
> rest of the application.=20

Sure. Every implementation of a crawler, extractor or whatever could=20
ship as a separate bundle with it's dependencies included. As such we=20
could manage the set of available implementations at will.=20
Implementations could be updated independently. The core bundle could=20
remain stable. The core interfaces wouldn't change that often.

We would get a simple, star-like dependency graph. With core, rdf2go and=20
some container or Model factory in the middle.

> However, more important IMO are the BundleActivators, as they require=20
> some programming as well as intimate knowledge of Aperture's internals=20
> and therefore you want to create them once and for all. Am I right in=20
> that the construction of the BundleActivators does not depend on the=20
> bundle granularity that you choose? Or can a bundle only have a single=20
> BundleActivator? In that case, perhaps BundleActivators can be chained,=
=20
> so that for example you have a single ExtractorsBundleActivator that on=
=20
> its turn invokes a HtmlBundleActivator, a PdfBundleActivator, etc.? Thi=
s=20
> would then support both the "1 extractor impl bundle" strategy and the=20
> "1 bundle per extractor impl" strategy.

I actually think it is a good idea.

> Again, my knowledge of OSGi is limited so feel free to say that this is=
=20
> all nonsense or has all been solved before.
>=20
My knowledge is limited to a 25-page tutorial :-). I would gladly hear=20
from those, who have more experience with OSGI.

Antoni Mylka
ant...@df...