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). 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. Greetings, Marcel
