i think distribution in OSGi is going to be a lot bigger over the next few years. It would be interesting to 
see how this works out.

I am expecting to see what new nice features of R-OSGi that can be provided with
the next version of R-OSGi.

added some details to the description.

some finishing touches on the description.

(In reply to comment #1)
> i think distribution in OSGi is going to be a lot bigger over the next few
years. It would be interesting to 
> see how this works out.

That's what I also think. It might be worth to discuss what different level of
distribution and integration into OSGi can be of value to open the OSGi platform
for distributed settings. This talk might be a good starting point.

Sounds like a very interesting talk, I am especially interested in learning how this technology scales to the 
smallest devices.

The topic sounds interesting, but I would like to also get a sense of how OSGi
adds value to this problem as opposed to we could do it with OSGi as well.

May be this is reaching too far, but are you making a case for using OSGi in
place of say sensor networks or Globus? Even if you are not, might be
interesting to hear why OSGi is better suited for massive distribution of
modularized software.

(In reply to comment #7)
> The topic sounds interesting, but I would like to also get a sense of how OSGi
> adds value to this problem as opposed to we could do it with OSGi as well.

This is intended to be addressed in this talk. On the one hand, it will be
discussed how the approaches covered by the specifications scale and behave. I
certainly don't want to give a sales speech for my research project. On the
other hand, R-OSGi is non-invasive. It is a middleware implemented as "just
another service" running on arbitrary framework implementations and allowing to
make use of all the benefits of standard (intra-framework) OSGi in distributed
setups.  
 
> May be this is reaching too far, but are you making a case for using OSGi in
> place of say sensor networks or Globus? Even if you are not, might be
> interesting to hear why OSGi is better suited for massive distribution of
> modularized software.

Although most of my (implemented) example deployments are of a smaller diameter
(for instance, I have Lego Mindstorm robots being controlled by R-OSGi), I have
use cases where massive distribution is an issue. I agree, a discussion how OSGi
is suited for these kinds of problems could get interesting. Actually, I am
currently writing a paper where I discuss some of the implications.

I really like this presentation because it is a key aspect of the work we will
be doing in the OSGi Enterprise Expert group. I also like the embedded
association which contrasts with much of the overwhelming attention of desktop
and server side computing.

Just curious, your distribution is based on distributed services? How invasive
is the distribution to a service user? I.e. UPnP and Jini are pretty invasive.

(In reply to comment #9)

I absolutely agree that UPnP and Jini are quite invasive. And each of the two
approaches has another major disadvantage: Jini requires a significant amount of
network infrastructure and management effort. UPnP restricts the arguments of
service methods to a small set of language-independent types, thereby limiting
the expressiveness of OSGi services. 
I worked a lot with both solutions and learned some lessons about the pros and
cons of the approaches. It is intended to share these experiences with the
people attending this talk, if it is accepted. 
We wanted to prevent both before-mentioned effects in our project and allow
service distribution even in ad-hoc networks of low-end computing devices, and
in a general way for every OSGi services. 
Concerning your question, the fundamental design principle of the system to
generate proxy bundles (on the fly) that register the (remote) service on the
local machine and redirect the method calls to the remote service. So for a
service user, the distribution is completely transparent. It's just an
additional service property (denoting the service provider host address) that
make distributed and non-distributed services distinguishable at all. (This
might in be useful in some situations, for instance, for management tools that
are aware of distribution.) 

There's been a STATUS change

Old Status: NEW 
Old Resolution: ACCEPTED

New Status: RESOLVED
Resolution: ACCEPTED

Comment:
Congratulations! You have been accepted for a long talk on EclipseCon 2007 in the OSGi track.

Great, thanks a lot ! I am looking forward to see you all in March.

There's been a STATUS change

Old Status: RESOLVED 
Old Resolution: ACCEPTED

New Status: SCHEDULED
Resolution: ACCEPTED

Comment:
No comments...

 Date: Wednesday   from 15:30-16:15 in Room 1

Created an attachment (id=303) [edit]
Paper

updated talk description.

Created an attachment (id=309) [edit]
Paper

updated the paper with a version that contains the proper Creative Commons
Metadata to avoid license issues.

Schedule Change: 07 15:30-16:20 Room 1

Schedule Change: 07 15:30-16:20 Grand Ballroom C

Reassignment of room

Created an attachment (id=510) [edit]
Slides

Added the presentation slides.