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@mail.osgi.org
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.
_______________________________________________________________________
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to