felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: OBR Resolver.deploy() and framework start level
Date Mon, 12 Feb 2007 19:10:20 GMT
Steven E. Harris wrote:
> "Richard S. Hall" <heavy@ungoverned.org> writes:
>> And, in general, it is not a good idea to make expedient decisions
>> because then it is hard to back away from them later.
> I understand.
>> The resource gives you the symbolic name and version, which uniquely
>> identifies the bundle.
> Yes, though unfortunately it's still an O(n) search to find the bundle
> this way.
> [...]

True, but I would assume that n is reasonably small since we are talking 
about installed bundles...even a 1000 or so shouldn't be an issue. If it 
is, you can easily construct your own map of installed bundles to search 
faster, since it isn't optimized under the covers either for quick 
lookup by symbolic name and version.

>> There is no association between a resource and an installed bundle
>> under the covers as you imply other than this.
> By "association", I was referring to the body of the Resolver.deploy()
> function which, while building its "start list" in the present
> incarnation, is able to get an actual Bundle instance in hand for each
> Resource it's operating on. It could return this "start list" to the
> caller as a Set<Bundle> or Bundle[], but we'd still be arguing over
> whether already-installed Bundles should be included in the returned
> list.
>> A thought, I could imagine another possibility, where the deploy()
>> method could return some sort of mapping between its resources and
>> the bundles it deployed or there could be another method that
>> returned this mapping after deploy() was invoked, since the resolver
>> would be able to construct this mapping while deploying the
>> resources.
> Yes, that's what I'm alluding to above. It could be the return value
> from deploy(), which at the moment only returns void, or it could be
> fetched by a subsequent method call if constructing the mapping is too
> expensive to do by default (even though it is best built during the
> deploy() method).
> As for whether it's a mapping from Resource->Bundle or just the
> Bundles themselves, I don't see much of a difference for my use
> case. I just want the Bundles.

Well, I am not against such an extension. We could always sub-class the 
resolver interface so we don't break from the "official" interface and 
add a method to get this mapping post-deploy().

I also think the resolver interface needs to be extended pre-deploy() to 
give a better indication of what will be installed and what will be 
updated (and possibly in the future, removed)...that is another 
different, but related issue.

-> richard

View raw message