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: Handling of provisional OSGi API
Date Fri, 17 Sep 2010 20:27:37 GMT
  On 9/17/10 12:54, Marcel Offermans wrote:
> On 17 Sep 2010, at 21:12 , Richard S. Hall wrote:
>> On 9/17/10 12:11, Richard S. Hall wrote:
>>> On 9/17/10 11:36, Marcel Offermans wrote:
>>>> On 17 Sep 2010, at 18:35 , Richard S. Hall wrote:
>>>>
>>>>>  From my point of view, approach (1) might not be awesome, but it results
in a simpler process than (2). So, I'd recommend (1). If the majority prefers (2), then we
can do that (although I think we'll have to run the decision by the board first).
>>>> I prefer (1) too.
>>>>
>>>> I could see us combine (1) with (2), releasing implementations with both
our own APIs which gives us the freedom to experiment with a new API whilst still "supporting
what's provided by public releases of draft specs.
>>> However, this doesn't avoid the IP grey of releasing "unofficial" APIs in our
"official" releases.
> Does the OSGi alliance disallow the inclusion of these "unofficial" APIs?
>
>>> Effectively, option (2) is a hybrid approach, since we couldn't make modifications
in the provisional API unless it were available in a public spec snapshot, so any modifications
would have to be done in felix package namespace. Which sort of makes (2) the worst of both
worlds.
>
> Well, if the snapshots are so outdated that it does not make sense to implement them,
then we should not even try. In that case, just stick to (1).

Sometimes it is not an issue of being out of date. If we want to 
implement a feature for potential inclusion into an RFC, then we run 
into the same issue if we add the feature to an existing OSGi API 
(whether it is provisional or not).

> I guess the other point would be for the OSGi Alliance to just develop new RFCs out in
the open, but as long as they're not, it's probably safer to ignore them if it could cause
problems otherwise.

Well, we don't want to ignore them since we want to implement the 
provisional specs and get experience with them. It is just difficult 
since our downstream users have no way of knowing what is official OSGi 
API and what isn't if we ship with provisional and/or modified org.osgi 
packages.

Even following option (1), it's still a tricky balancing act, especially 
in cases where we might actually provide the RI, such as Gogo or CM. But 
this is more difficult for us since we release early and often as 
opposed to Eclipse which releases yearly.

-> richard

Mime
View raw message