Posted by
CmdrTaco
on from the from-the-research-center-that-brought-us-everything-else dept.
Sandeep writes " PARC announces a new software architecture , named Obje, to establish a device-independent networking system. Essentially, it allows two devices to teach each other how to talk amongst themselves. It does this by sending actual code over the network."
RTFA before replying - oh wait, you can't -
by
Wingchild
·
· Score: 4, Informative
because the real link is here. The one supplied in the story 404'd on me.
Thanks, Google!
Sun already tried this
by
kroekle
·
· Score: 4, Informative
This sounds like what Sun tried to do with Jini. Judging buy the success (or lack there of) of Jini, I don't believe this will be successful.
Re:Sun already tried this
by
JBMcB
·
· Score: 4, Informative
Jini was/is a great idea. Plug in a printer, it uploads it's driver to the computer. Put it on a network, any computer that connects to it automatically gets the driver.
Sounds kind of like what Apple is doing with Rendezvous. uPnP should die a quick death.
-- My Other Computer Is A Data General Nova III.
Re:Sounds Like Sun's JINI
by
Anonymous Coward
·
· Score: 5, Informative
Q. How is the Obje interoperability platform different from UPnP? Jini? A. The key difference between the Obje technology and other approaches to interoperability is that Obje does not require prior agreement on domain specific interfaces--the protocols, encodings, and standards used to communicate with specific types of devices. Other technologies, including UPnP, Jini, HAVi and Bluetooth, each define specialized interfaces for each new type of device: Bluetooth defines "profiles" for phones, headsets and printers; Jini defines APIs for printers and cameras; the UPnP consortium defines interfaces for audio/visual devices, scanners and home appliances; HAVi defines APIs for DVD and CD players, printers, cameras and TVs.
The problem with such approaches is that software must be recoded to address each specific type of device that it is expected to work with. For example, an application written to use UPnP media servers will not be able to use UPnP scanners (much less devices implemented under other standards) without re-implementation.
With Obje, devices and applications are written once, against a small, fixed set of meta-interfaces, which allow them to acquire any needed communication capabilities at runtime. These meta-interfaces abstract the protocols and communication standards used by specific devices so that, at runtime, a device can provide its communication specifics to the entity that wants to use it, with no reprogramming of existing services. This allows users and manufacturers to "recombine" devices and services at will, without waiting for slow-moving standards bodies. This ability is unique to Obje.
Re:And in other news...
by
Anonymous Coward
·
· Score: 1, Informative
Note: Steve Jobs monster home is in downtown Palo Alto (a short drive from the PA airport helipad... and his aerial commute to Pixar).
PnP + Windows Update + ...
by
Wingchild
·
· Score: 4, Informative
All Obje devices or services, called components, implement and make use of one or more of the meta-interfaces. Together, the Obje meta-interfaces allow components to extend one another to accept new data transfer protocols, media formats, CODECs, content types, discovery protocols, physical network transports, and user interfaces. An Obje component, or client application written against the framework, automatically acquires the above dimensions of extensibility, allowing it to interoperate with new peers on the network without rewriting and without explicit software updates.
To wit:
data transfer protocols: Are you on TCP/IP, or UDP, or Appletalk, or what? Let me adapt.
media formats: What type of streaming content is that, exactly? Let me adapt.
CODECs: You're using Divx/MPEG-4? I don't have it, send it to me as part of the framework package.
content types: I can't support that MIME type. Teach me, via the framework, how to handle it.
discovery protocols: I didn't come with the latest wireless discovery standard; hello, access-point that's Obje enabled, please teach me how to access you... in the meantime, I'll talk to you using my own special discovery protocol.
and etc.
All of these things can already be done and are being done and have been done and were done years ago; Obje seems like a unification of all those efforts, moving towards a central platform-independant standard for how devices learn to do new tricks. Much as when you're surfing the net now and your browser auto-learns how to play new types of Media because a website can push you the players, except extended to higher (and lower) order functions as well, because PARC seems to be betting on awesomely small future computers that will have to be able to handle a very wide range of user functions.
The only thing that has to be prearanged is a protocol for this transaction. I don't need to maintain an extensive driver library for this to work.
Reference the Amiga Computer and its use of Autoconfig, before windows attempted their version with "plug and pray."
God, I miss that machine.
Re:Extensive Driver Libraries
by
drinkypoo
·
· Score: 2, Informative
Except the amiga had the entire driver for the hardware in adapter ROM (except in cards where the driver had to be installed via software, of course, and loaded during the boot process, or referenced from your mountlist or devslist.) This was possible (for the people who don't know enough to miss it) because everything was a user-level process, including filesystem drivers, and hardware drivers. Hence you had a process perhaps called scsi.device and a process called FastFileSystem, and so on. Very slick, very sexy, these days it would only be good for handheld devices and thin clients in its original no-memory-protection form, but it was very cool for its time, when almost no one used memory protection. Including Windows and MacOS (in spite of the fact that most wintel machines and probably half to three quarters of the macs had a moto cpu with a mmu.)
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Can anyone find downloadable code?
by
gabbarsingh
·
· Score: 2, Informative
I checked out the whitepaper, it reads like an executive summary. The whitepaper acknowledges existing discovery mechanisms and proposes an elementary solution using meta-interfaces. Well duh I knew that yesterday. Where's the code, dude? Seems like one has to enter into some sort of licensing arrangement to even find out if they really have something that works.
Don't get me wrong, there is some super talented people on the team - but I can't buy what I can't see. And this is precisely why I love GPL.
Jini sucks, and here's why
by
gabbarsingh
·
· Score: 2, Informative
Jini is related to Obje not only in semantics but the same dudes (atleast Keith Edwards) worked on Jini. I used Jini since its inception only to find out that:
- like Java, its spec is controlled by Sun which is good 'cause there a single controlling entity and the bad is that no device manufacturer gives a rat's ass about what Sun thinks about device discovery and service negotiation.
- Working with non-Java entities requires some sort of proxy and/or surrogate architecture i.e. shoehorn a protocol into it and if the protocol doesn't exist already well, write one and shoehorn it. Well, I don't think so - that's what I wanted to cure in the first place.
On top of that the one and a half other implementations don't interoperate successfully.
reinventing the wheel
by
ajagci
·
· Score: 3, Informative
Not surprisingly, people have been working on this for many years. In particular, DAML is about. Sure, DAML work is being done in the framework of software agents on the web, but it's the same problem: having services that don't know about each other ahead of time figure out for themselves how to talk to each other. Furthermore, the technologies that have been developed as part of the work on the semantic web already seem considerably more sophisticated than the "Obje" framework.
Re:Parent should be "Insightful," not "Funny"
by
drinkypoo
·
· Score: 2, Informative
This is what Open Firmware does for basic boot devices, and if we extended OF to peripherals, we wouldn't have this problem - Except instead of BASIC, which is a basically (h0 h0) functional but uninteresting language, it uses FORTH. FORTH is more efficient than BASIC and as such makes a better language for BIOS operations on systems with little CPU power, like old 16MHz SPARCstations. Open Firmware is a standard now and is used by Apple and Sun. This is the reason why Sun consoles have traditionally been so slow, during the boot process (until some other software graphics driver is loaded) all of your text drawing is done through interpreted FORTH - this is from the days before JIT recompilation became ubiquitous, of course.
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Slashdot Mirror
because the real link is here. The one supplied in the story 404'd on me.
Thanks, Google!
This sounds like what Sun tried to do with Jini. Judging buy the success (or lack there of) of Jini, I don't believe this will be successful.
Q. How is the Obje interoperability platform different from UPnP? Jini?
A. The key difference between the Obje technology and other approaches to interoperability is that Obje does not require prior agreement on domain specific interfaces--the protocols, encodings, and standards used to communicate with specific types of devices. Other technologies, including UPnP, Jini, HAVi and Bluetooth, each define specialized interfaces for each new type of device: Bluetooth defines "profiles" for phones, headsets and printers; Jini defines APIs for printers and cameras; the UPnP consortium defines interfaces for audio/visual devices, scanners and home appliances; HAVi defines APIs for DVD and CD players, printers, cameras and TVs.
The problem with such approaches is that software must be recoded to address each specific type of device that it is expected to work with. For example, an application written to use UPnP media servers will not be able to use UPnP scanners (much less devices implemented under other standards) without re-implementation.
With Obje, devices and applications are written once, against a small, fixed set of meta-interfaces, which allow them to acquire any needed communication capabilities at runtime. These meta-interfaces abstract the protocols and communication standards used by specific devices so that, at runtime, a device can provide its communication specifics to the entity that wants to use it, with no reprogramming of existing services. This allows users and manufacturers to "recombine" devices and services at will, without waiting for slow-moving standards bodies. This ability is unique to Obje.
Note: Steve Jobs monster home is in downtown Palo Alto (a short drive from the PA airport helipad... and his aerial commute to Pixar).
From the Obje FAQ:
... in the meantime, I'll talk to you using my own special discovery protocol.
All Obje devices or services, called components, implement and make use of one or more of the meta-interfaces. Together, the Obje meta-interfaces allow components to extend one another to accept new data transfer protocols, media formats, CODECs, content types, discovery protocols, physical network transports, and user interfaces. An Obje component, or client application written against the framework, automatically acquires the above dimensions of extensibility, allowing it to interoperate with new peers on the network without rewriting and without explicit software updates.
To wit:
data transfer protocols: Are you on TCP/IP, or UDP, or Appletalk, or what? Let me adapt.
media formats: What type of streaming content is that, exactly? Let me adapt.
CODECs: You're using Divx/MPEG-4? I don't have it, send it to me as part of the framework package.
content types: I can't support that MIME type. Teach me, via the framework, how to handle it.
discovery protocols: I didn't come with the latest wireless discovery standard; hello, access-point that's Obje enabled, please teach me how to access you
and etc.
All of these things can already be done and are being done and have been done and were done years ago; Obje seems like a unification of all those efforts, moving towards a central platform-independant standard for how devices learn to do new tricks. Much as when you're surfing the net now and your browser auto-learns how to play new types of Media because a website can push you the players, except extended to higher (and lower) order functions as well, because PARC seems to be betting on awesomely small future computers that will have to be able to handle a very wide range of user functions.
Reference the Amiga Computer and its use of Autoconfig, before windows attempted their version with "plug and pray."
God, I miss that machine.
I checked out the whitepaper, it reads like an executive summary. The whitepaper acknowledges existing discovery mechanisms and proposes an elementary solution using meta-interfaces. Well duh I knew that yesterday. Where's the code, dude? Seems like one has to enter into some sort of licensing arrangement to even find out if they really have something that works.
Don't get me wrong, there is some super talented people on the team - but I can't buy what I can't see. And this is precisely why I love GPL.
Jini is related to Obje not only in semantics but the same dudes (atleast Keith Edwards) worked on Jini. I used Jini since its inception only to find out that:
- like Java, its spec is controlled by Sun which is good 'cause there a single controlling entity and the bad is that no device manufacturer gives a rat's ass about what Sun thinks about device discovery and service negotiation.
- Sun's implementation needs Java2 i.e. 10MB JVM w/ 30-40MB runtime footprint
- Working with non-Java entities requires some sort of proxy and/or surrogate architecture i.e. shoehorn a protocol into it and if the protocol doesn't exist already well, write one and shoehorn it. Well, I don't think so - that's what I wanted to cure in the first place.
On top of that the one and a half other implementations don't interoperate successfully.
Not surprisingly, people have been working on this for many years. In particular, DAML is about. Sure, DAML work is being done in the framework of software agents on the web, but it's the same problem: having services that don't know about each other ahead of time figure out for themselves how to talk to each other. Furthermore, the technologies that have been developed as part of the work on the semantic web already seem considerably more sophisticated than the "Obje" framework.
This is what Open Firmware does for basic boot devices, and if we extended OF to peripherals, we wouldn't have this problem - Except instead of BASIC, which is a basically (h0 h0) functional but uninteresting language, it uses FORTH. FORTH is more efficient than BASIC and as such makes a better language for BIOS operations on systems with little CPU power, like old 16MHz SPARCstations. Open Firmware is a standard now and is used by Apple and Sun. This is the reason why Sun consoles have traditionally been so slow, during the boot process (until some other software graphics driver is loaded) all of your text drawing is done through interpreted FORTH - this is from the days before JIT recompilation became ubiquitous, of course.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"