"Richard S. Hall" <[EMAIL PROTECTED]> writes:

> Yes, if you try to install a bundle with a symbolic name/version it
> will fail, no matter what the location string is.

I may have misquoted Mr. Hargrave, but I think he refined this
situation to say, if the location string of the new bundle and the
currently installed bundle's location strings match, no error is
signaled, and the current Bundle is returned.

> To summarize:
>
> You cannot install two bundles with the same location string.
> You cannot install two bundles with the same symbolic name/version.
>
> The two statements are independent of each other.

Got it.

> If you wanted to be sure that it wouldn't fail for this reason, then
> yes you would have to. But what is the point? It could fail for
> other reasons too, so are you going to check all of those reasons in
> advance too?

Here's why it's different: If it fails for the first reason, because
the bundle is already installed, then I know I can carry on knowing
all is well. The intention was to get some bundle installed. If it
turns out it was already installed, then there is no problem; I was
done before I started.

But if installation fails for some other reason, I'm stuck unable to
discern whether the installation failed due to a duplication conflict
or due to data corruption. I don't know afterward whether I can assume
this bundle is already installed.


To further disclose the motivating situation, my current design for my
client-server interaction has the server saying, "Here are a bunch of
resources (which are probably all bundles). These resources are
prerequisites for some services I want you to use." The server wants
the client to locate some registered services by providing key-value
pairs to form a filter string. The server knows which bundles host
these services, but the server doesn't know if the client already has
these bundles installed, so it recommends the client install these
bundles every time it recommends the client use some services hosted
by these bundles.

One simple way to solve this problem is to have the client try out
using the filter string before trying to install the associated
bundles. If the filter gets a hit, the bundle is probably already
installed. If the filter gets no hits, the client should try
downloading and installing the bundles, then try the filter
again. This approach misses out on the possibility of updating an
installed bundle that provides a superseded version of the service --
but then services should really be versioned to catch that case.

You may also ask why the server isn't telling the client explicitly
which symbolic-name/version pairs to install. I'm trying to keep OSGi
out of the protocol, by not explicitly mentioning concepts that are
specific to OSGi. Hence my preference for the server to prescribe
opaque resources for the client to download, with a MIME type (via an
HTTP Content-Type header) hinting as to whether to try installing the
resource as an OSGi bundle.

Best of all would be to push all the bundle procurement into OBR. The
server could specify a symbolic-name/version pair as a prerequisite
(or, more abstractly, package names and versions) to construct a
filter to pass to RepositoryAdmin.discoverResources(), then adding
those Resources to a Resolver for resolution and deployment. OBR
handles the case of locally-installed resources filling
requirements. I'm just not sold on the idea of maintaining a
repository.xml file that each client must download.

-- 
Steven E. Harris

Reply via email to