Re: Put API/SPI/implementation into separate bundles?

To expand on this train of thought as it's getting on towards of end of 
day here in the UK so I feel the urge to talk to the wall ;)

The consideration when building bundles is how best to weight the 
distribution of code between bundles is which code belongs together from 
a client perspective. As with all API decision the designer needs to put 
themselves in the clients shoes to decide the correct grouping of classes.

From my view point I try to ensure where ever possible that API bundles 
should be dependent only on other API bundles. This limits the possible 
spread of the graph beyond the classes need to express the core 
semantics of the API.

The pain comes when trying to start client code that depends on an api 
and you end up in the cyclical process of resolving the next bundle 
required to start.

In newton where we're dealing with remote deployment of bundles this 
also has a performance aspect as client code should not depend on 
downloading server implementations in order to function.

Possible analogies can be made with physical phenomena such as center of 
mass and entanglement. You don't want to have to drag down the weight of 
an entire planet just to switch a light switch etc.

So in summary my advice would be to separate impl and api but do so in 
such a way as to inherit apis and group related apis for semantic 
coherency - simple :)

Regards,

Dave

(shameless link to newton)
http://newton.codecauldron.org

David Savage wrote:
> Jeff McAffer wrote:
> > > Leaping on this thread as it's something I've had a lot of experience
> > > unpicking and wouldn't want others to have same pain.
> > >
> > > Another issue that is worth considering (and yet another reason to
> > > separate into api and impl) is that due to osgi resolution requirements
> > > if you put your impl in the same bundle as the api this effectively
> > > requires client code to resolve bundles that your impl uses but they
> > > may
> > > have no need of using.
> > >
> > > This can rapidly get out of control and in the worst case a client
> > > needs
> > > to import a much larger set of bundles to use a client api than would
> > > otherwise be needed.
> >
> > Yes, this is definitely a concern.  Just to paint the flip side of the
> > spectrum, if you put the API in a separate bundle then either you have 
> > a lot
> > of small bundles (high overhead ratio in management and runtime foot 
> > print)
> > or you lump together unrelated API and have a similar problem to what you
> > describe.
> >
> > I'm not countering but rather suggesting that there is not a single, one
> > size fits all answer.
>
> Agreed on all points.
>
> Regards,
>
> Dave.
>
> > Jeff
> >
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev-KBXktWM7AvLsrOwW+9ziJQ@xxxxxxxxxxxxxxxx
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
> > _______________________________________________________________________
> > This email has been scanned by both Message Labs and Paremus internal 
> > systems for viruses and inappropriate attachments.  Email suspected of 
> > carrying a virus payload or inappropriate attachment will not be 
> > delivered to you, and the sender will receive an appropriate warning 
> > notice.
> > _______________________________________________________________________


_______________________________________________________________________
Paremus Limited. Registered in England
No. 4181472
Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
Postal Address: 107-111 Fleet Street, London, EC4A 2AB
The information transmitted is intended only for the person(s) or entity to 
which it is addressed and may contain confidential and/or privileged material. 
Any review, retransmission, dissemination or other use of, or taking of any 
action in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited.
If you received this in error, please contact the sender and delete the 
material from any computer.
_______________________________________________________________________