9 ms·

What specifically has Jini got to do with this?

by melange 13y ago

projectileboy 13y ago
Jini was trying to solve the same sorts of problems. I mention it because when we look at a new technology, it's often instructive to look at older technologies that were trying to solve the same (or similar) problems. In particular, it's helpful to look at why they succeeded and why they failed. For example, the "web services" community would have been well-served by looking at the successes and failures of CORBA, since the web services folks mostly replicated all the mistakes of CORBA.
- twoodfin 13y ago
  Was that really an accident? I know many of the WS-* proponents liked to say, "This new web-based technology will be so much simpler than that crufty old CORBA junk." But in many cases it was the same companies with the same agendas doing the design and standardization work, so it's not too surprising that the result was more or less bound to go down the path of CORBA. The main difference, and of course the main motivation, was a protocol that would run on port 80 and have a chance to be "web-routable" through firewalls.
  - projectileboy 13y ago
    That's a really good point. Certainly the product vendors had the same motivations. But at the time I was often disappointed when I listened to the conversations of developers I worked with, because I rarely heard anyone draw parallels between the two. It was frustrating to work on projects where we'd be six months in and people would be surprised that the ORBs - er, I mean web service platforms - had difficulties talking to one another.
    - spullara 13y ago
      It wasn't just the product vendors. The people on the two specs were also the same. WS-* was literally the ex-CORBA contributors reimplementing all the same stuff.
- melange 13y ago
  I don't really see how Jini was trying to solve the same problems. iBeacons are really just a simple way to discover devices nearby broadcasting a UUID. Jini was a super complicated attempt to create a distributed device fabric, which included interface negotiation and driver distribution and all kinds of other complex infrastructure, most of which is redundant now.

What specifically has Jini got to do with this?

by melange 13y ago

What specifically has Jini got to do with this?

Jini was trying to solve the same sorts of problems. I mention it because when we look at a new technology, it's often instructive to look at older technologies that were trying to solve the same (or similar) problems. In particular, it's helpful to look at why they succeeded and why they failed. For example, the "web services" community would have been well-served by looking at the successes and failures of CORBA, since the web services folks mostly replicated all the mistakes of CORBA.

twoodfin 13y ago
Was that really an accident? I know many of the WS-* proponents liked to say, "This new web-based technology will be so much simpler than that crufty old CORBA junk." But in many cases it was the same companies with the same agendas doing the design and standardization work, so it's not too surprising that the result was more or less bound to go down the path of CORBA. The main difference, and of course the main motivation, was a protocol that would run on port 80 and have a chance to be "web-routable" through firewalls.
- projectileboy 13y ago
  That's a really good point. Certainly the product vendors had the same motivations. But at the time I was often disappointed when I listened to the conversations of developers I worked with, because I rarely heard anyone draw parallels between the two. It was frustrating to work on projects where we'd be six months in and people would be surprised that the ORBs - er, I mean web service platforms - had difficulties talking to one another.
  - spullara 13y ago
    It wasn't just the product vendors. The people on the two specs were also the same. WS-* was literally the ex-CORBA contributors reimplementing all the same stuff.
melange 13y ago
I don't really see how Jini was trying to solve the same problems. iBeacons are really just a simple way to discover devices nearby broadcasting a UUID. Jini was a super complicated attempt to create a distributed device fabric, which included interface negotiation and driver distribution and all kinds of other complex infrastructure, most of which is redundant now.