Re: Jini vs/and OSGi

Niclas Hedhman wrote:

> Yes, I was part of the spectacle. Politics from all over the place, including
> the RMI team in Boston, who IMHO pushed the EG to go for public review before
> the specification was satisfactory from a technical perspective, since it HAD
> TO be part of Java 1.3 (or was it 1.4?) release, soon around the corner.

Unfortunately I'm not able to comment on the outcome because at those
days (and to some extent these days still) the discussions of the expert
groups are private. In Holland you can ask for a "Parliament Enquete" in
which they investigate how these things could have happened, maybe it
would be nice to have such a thing too for the JCP. At least it would
give us a lot of publicity ;-)

Given the fact the result of those 2 JSRs were further developed by the
Jini community in the Davis project, I think it is safe to say the end
result is better than it would have been if those 2 JSRs would have been
approved, so I see at least one positive side for the outcome. As such I
could understand the desire to go public early, although I'm not sure
what that would have meant exactly.

> The Service layer in OSGi has a huge conceptual overlap with the service
> notion in Jini. The dynamic properties of things coming and going are the
> same. Notifications via events are essential in both. Security is central.
> I can create a LookupCache in Jini or a ServiceTracker in OSGi to be notified
> of changes in the service, such as the meta-data (properties) of it.

While I agree there is a huge conceptual overlap, I also believe the
interfaces you see for those concepts differ exactly due to the nature
for which they were developed, local versus remote. Maybe they can be
bridged but I don't believe you morph both in something that would do
justice to both domains.

> Yeah, not speaking of "publicly" as in going into a sales position, but I was
> refering to 'here'. Gregg says; "OSGi can't give me anything" and I have
> heard Dan, you and others essentially saying that "Here is a list of
> scenarios where OSGi can't be used, and here is another list of stuff I would
> loose out on if I deploy on OSGi, and here is a list...."

No denial here. It will require people that want to spend their time for
these things, either because they feel the itch or they see a huge
opportunity. I think you are right in framing some in not having the
itch as we feel it doesn't bring us something we need. I would have
preferred 'egocentric' over 'egoistic' though given the connotation of
the latter, I see it as that you just can't be everywhere to reach a hand.

Luckily some other members of this community have the itch and I'm very
interested to see where this is going and I hope/expect them to suggest
improvements to the class loading model that would bring it in line with
OSGi and/or the other way around but that would work for a non OSGi Jini
too, taking into account what is required for security in a mobile code
world. As Dan just said everybody can bring their suggestions to the
table for others to comment on. In this community I always felt that if
people wanted to get something done that was more than a shot in thin
air, the people with the knowledge to make sensible comments were
willing to do that. But I think you can't expect to them to solve the
problems that are likely not theirs.

BTW with regard to Spring doing an RFP. I guess that is a different
situation, not only is that a much bigger community, Spring is like the
Borg they won't rest before the whole world is wrapped behind their APIs ;-)
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]