The reason why we are considering allowing multiple hosts to use the
same fragments is because we run in version problems. Allowing only
one host to use a fragment, means that you have to disallow some hosts
to use a fragment or connect them to an older version. I tried to
describe this and it was terribly ugly and sounded very arbitrarily.
We discarded the multiplicity because we could not figure out a number
of details in time for R4 and felt it was easier to later relax the
spec than to narrow it one day. Believe me, we spent an insane amount
of time on these issues because we all want to keep the spec clean and
small ...
Kind regards,
Peter Kriens
AC> My humble thoughts:
AC> Like any good work of art it is hard to know when enough is enough
AC> and it's time to leave the piece as it is. I am worried that what
AC> was once a clean and elegant spec will become muddied to support
AC> features that, imo, tools should have taken the burden; take required
AC> bundles for example.
AC> I'm not aware of the compelling use cases that call for an extension
AC> to the number of hosts for a fragment but can think of one, again
AC> imo, not so compelling one. This being the patching of a set of
AC> bundles with one fragment. I'm happy to go into detail as to why I
AC> think poorly of this use case if it is the impetus for adding this
AC> extension and if this is the appropriate forum.
AC> About PackageAdmin.getHosts(), I assume that for the moment it should
AC> always return a single host. Just curious, was there a reason to
AC> have it still return an array and not a scalar in light of the
AC> current cardinality between host and fragment?
AC> Is there a way for me to know what's in the pipeline so that I may
AC> put in my 2 cents?
AC> Regards,
AC> Alan
AC> On Oct 2, 2007, at 5:42 AM, BJ Hargrave wrote:
>> :-)
>>
>> During R4 spec development we allowed fragments to attach to multiple
>> hosts. Prior to going final on R4, we changed course and limited
>> fragments
>> to only attach to a single host. The sentence you quote is left
>> over from
>> when we considered allowing fragments to attach to multiple hosts.
>> Also
>> see the method signature of PackageAdmin.getHosts where the return
>> type is
>> an array and not a scalar.
>>
>> We are currently discussing revisiting that decision. That is, to
>> potentially allow a fragment to attach to multiple hosts. It would be
>> useful to get input from the OSGi community on the pros and cons of
>> such a
>> change.
>> --
>>
>> BJ Hargrave
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the OSGi Alliance
>> [EMAIL PROTECTED]
>>
>> office: +1 386 848 1781
>> mobile: +1 386 848 3788
>>
>>
>>
>>
>> From:
>> Alan Cabrera <[EMAIL PROTECTED]>
>> To:
>> OSGi Developer Mail List <[email protected]>
>> Date:
>> 2007-10-02 02:07
>> Subject:
>> [osgi-dev] Finding Localization Entries
>>
>>
>>
>> Hello,
>>
>> I'm trying to get my head around 3.10.1 Finding Localization
>> Entries. The last sentence of the first paragraph confuses me.
>>
>> "Fragment bundles must delegate the search for a localization entry
>> to their host bundle with the lowest bundle ID."
>>
>> Does this mean that fragment bundles can have multiple hosts?
>>
>>
>> Regards,
>> Alan
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> http://www2.osgi.org/mailman/listinfo/osgi-dev
>>
AC> _______________________________________________
AC> OSGi Developer Mail List
AC> [email protected]
AC> http://www2.osgi.org/mailman/listinfo/osgi-dev
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
