Niclas Hedhman <[EMAIL PROTECTED]> writes: > Actually not. The URL could be just a http:// ref to a bundle, but > what to do with that is OSGi specific, and hence part of the code > executing in the target.
Well, if we review the discussion thread again, my concern was that a URL like this gives no hint to the consumer /which/ bundle is being referred to. The only way to find out is to download it and try to install it. If the installation fails, you can't tell whether it failed because the bundle was already installed or because the downloaded JAR file was corrupted, or maybe some other random IO error got in the way. My goal is not just to enable retrieval of bundles over the network, but to allow the server to specify prerequisites to the client: "You need this bundle available for the next operation; if it's not available locally, download it and install it." That helps avoid the unnecessary downloading of a bundle that's already installed. I can rely on OBR for most of the actual retrieving and installing parts, but it's essential that I know up front which prerequisite I'm trying to meet. Using OBR for my purpose -- or, in its absence, doing much of what it does manually -- requires me to know up front which bundle symbolic name (and, optionally, version, or some other filter criteria) satisfies my prerequisite directive. An opaque HTTP URL doesn't tell me enough without actually dereferencing it. This whole argument about needing to deal in terms of prerequisites arises from the problem of not being able to blindly install any downloaded bundle. Bundle installation is not idempotent, and the current installation interface does not allow one to discern an overlap (goal already satisfied) from a failure (goal not satisfied). Hence, one needs to check-then-act when it's possible that a prescribed bundle is already present. Checking whether it's present requires one to know some of the prescribed bundle's identity. An opaque URL does not reveal enough for that purpose. -- Steven E. Harris _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
