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."
Re:Only two possible outcomes.
by
Frymaster
·
· Score: 4, Insightful
Only two possible outcomes.
you forgot the third option:
3. xerox will let this wither away in the lab just like all those other great parc ideas and we won't see it for another decade when someone with the actual common sense to build and sell the damn thing happens to get a peek at it through the window.
this is the most likely result. i blame it on the fact that the xerox corporate culture has been so built on the "copier" mentality that they can't recognize the value of an original.
Microsoft already has this patented feature in OE and IE.
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:Sun already tried this
by
NSash
·
· Score: 3, Interesting
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.
On the contrary, a sign of a great idea is that even if the market doesn't accept it at first, it keeps on returning until its time has come.
Parent should be "Insightful," not "Funny"
by
Anonymous Coward
·
· Score: 4, Insightful
I simply can't imagine that this could be done in a secure fashion between any two arbitrary devices that don't know what the other is.
Re:Parent should be "Insightful," not "Funny"
by
drinkypoo
·
· Score: 5, Insightful
Simply enough, you don't trust the other end, and all code is run in a sandbox. If the code does anything strange the session is terminated, if the other system (or peripheral) hands you strange code too many times you just stop listening. I don't think it's really necessary to send code, it would be just as well to send a list of capabilities (shades of my HVAC discussion) and then the sytem decides what you are based on your capabilities and treats you accordingly.
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:Parent should be "Insightful," not "Funny"
by
Short+Circuit
·
· Score: 4, Interesting
Perl supports "tainting" of data, so you don't do accidentally anything stupid with information that isn't secure. (Including exec'ing it.)
I imagine this would be a similar set up.
Or it could be done inside a virtual machine ala JVM, with a stream output to the part of the device that actually uses whatever the communication is intended to transmit in the end.
Re:Parent should be "Insightful," not "Funny"
by
jilles
·
· Score: 5, Interesting
With Java you can do this. Just run the code in a sandbox. Alternatively you can use some trusted third party and signatures. Or you can do both (authenticate other party and allow verified and validated code to do whatever it is authorized to do). The JINI architecture works along these lines (although it seems rather dead nowadays). It can be very secure if you set it up properly.
--
Jilles
Re:Parent should be "Insightful," not "Funny"
by
BlueTooth
·
· Score: 5, Interesting
and then the sytem decides what you are based on your capabilities and treats you accordingly.
This assumes that the system already knows about all possible capabilities and that it knows how to talk to everyone else.
I think the idea is that devices teach each other of their existence. It would be like if I bought a USB device (say a camera) that Windows didn't support, the camera would be able to bootstrap Windows with some drivers from its own firmware. 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.
-- SPAM
Re:Parent should be "Insightful," not "Funny"
by
goatwhip
·
· Score: 5, Interesting
What portion of detecting whether code sent to you over the network is doing something 'strange', do you find simple?
I hate it when people preface comments with "Simply enough" or "Obviously". It automatically makes anyone who doesn't understand what the person is talking about, feel stupid.
Re:Parent should be "Insightful," not "Funny"
by
The+Spoonman
·
· Score: 4, Insightful
It would be like if I bought a USB device (say a camera) that Windows didn't support, the camera would be able to bootstrap Windows with some drivers from its own firmware.
I've been saying for years "Flash ram is cheap, put some in every device to contain a BASIC device driver. The real driver can then be loaded to deliver the total package."
This all started years ago when Intel, in their infinite wisdom, started packaging the drivers for their cards with tons and tons of crap, so that I had to download a 9M file just to get a 10K driver file! Uh, schmucks, that won't fit on a floppy, and if I can't get on the network to download it, I have waste a fucking CD to get your driver!
For some reason, it amazes me how few people actually do any thinking.
-- Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
Re:Parent should be "Insightful," not "Funny"
by
blamanj
·
· Score: 3, Insightful
Exactly. For all the hand-wringing about security, you'd think people had never heard of Java applets, which, suprise, send code over the network.
The applet/sandbox has proven far more secure than scripting languages and even applications like the browsers themselves.
Re:Parent should be "Insightful," not "Funny"
by
drinkypoo
·
· Score: 3, Insightful
What they're talking about here is getting data to/from a device whose capabilities are not precisely known. Therefore I assume that the interface speaks mostly in abstracts. The driver you write (which is basically going to have to run in a sandbox of some sort; if it uses a simple enough (actually, complex enough, and high-level) language there simply won't be any way to do harm (outside of consuming resources, which can be solved by simply not allocating them to you past a certain point) within the constraints of the language in the first place.
Essentially your interface will have a way for something to connect to it and get data from it or put data on it. I assume in general the code sent is meant to be a driver of some sort and it will carry out a protocol, whereas all the OS has to do is shovel it some data, or get some data from it. The API will be analogous to SCSI which basically has only a few commands which are used for everything; the driver (which will run in the sandbox) is the interface between the drive's electronics and the SCSI bus. The difference is that it's in software and the driver has to run on the server. Why this is so much better than just picking a standard and following it, I'm not sure, but then I didn't RTFA. In theory it will allow you to use arbitrary capabilities of a device, but on the other hand you're still going to need an application that knows what to do with the data. I can think of several ways to handle it otherwise, all of them bad, and none of them which would work reliably. Then again, these guys know more than I do, which is why they get paid the big bucks, and I don't:)
-- "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Atleast we know they can't patent it.
by
Monkelectric
·
· Score: 4, Funny
MS definatley has pior art on arbitrary code execution (I'm look at you, Outlook).
--
Religion is a gateway psychosis. -- Dave Foley
Whats wrong with generated code?
by
SkunkPussy
·
· Score: 4, Interesting
There is nothing wrong with generated code if you trust the sender. Plus if the code sent over the network is executed in a sandbox/jvm it shouldnt be incredibly risky (obviously a lot of potential for DoS attacks).
Code can be a very concise way to express an algorithm.
-- SURELY NOT!!!!!
Re:Whats wrong with generated code?
by
NSash
·
· Score: 5, Funny
Code can be a very concise way to express an algorithm.
And to think that all this time, I was expressing my algorithms in pictograms!
Re:Whats wrong with generated code?
by
GileadGreene
·
· Score: 3, Funny
And to think that all this time, I was expressing my algorithms in pictograms!
Yeah, pretty much everyone seems to use UML these days...
Keep in mind I have only SkimmedTFA... This seems like it would be useful for forming ad hoc networks, for example in a disaster or emergency scenario. But for frequent daily use, it seems like it might be a particularly vulnerable protocol.
Are the benefits of high quality and reliable communication in a disaster/terrorism situation worth the potential risks of insecurity in that situation?
if you're sending code over the network in order to communicate, why have a traditional network at all? Why not just synchronize all the files between all the machines, or just have terminals? It seems like a mistake to send code for anything as a part of initiating network communication. PC 1: "here's how to hack me." PC 2: "OK! sending hack." PC 1: "thanks! Now I'm hosed." PC 2: "no prob. see you in hell! ha ha ha!"
Re:Why even have a network?
by
truthsearch
·
· Score: 3, Interesting
If code is instruction for a computer, why not send instruction over the network? As opposed to pure data ("Here's a packet of info"), it makes sense to send "I'm here and I'm a device of type X. When Y happens, send me Z." If the code is limited in its abilities, and isn't just run arbitrarily, the network itself can contain much logic. Devices could then use the network is much more logical and efficient ways.
DMCA and other viruses
by
buckhead_buddy
·
· Score: 4, Interesting
The propogation of code is worrisome, but I'm also unsure of the legal implications of allowing your code to accept the code and restrictions of others by automatically allowing it to run.
This may be a neat new way to logically propogate code, but once all the kinks are worked out it seems like it simply opens new doors for lawyers to battle out THEIR logic.
Brrrr
that's stupid
by
Anonymous Coward
·
· Score: 4, Insightful
what is wrong with the existing protocol specs and RFCs? As it is, we have enough security problems even with a meticulous protocol specification. So making it more arbitrary will help? I doubt that, unless we are just willing to concede that security is a hopeless quest.
Essentially, it allows two devices to teach each other how to talk amongst themselves.
What happens if one of them starts to get a little verklempt?
--
Until Slashdot fixes the funny modifier, use insightful or interesting. The poster knows your intentions.
How to use it?
by
tcopeland
·
· Score: 4, Insightful
Answer:
Q. What does an equipment manufacturer or service provider need to do to Obje-enable a device, service, or product line? A. Please contact us for co-development and licensing information.
heh - The infinite IS possible with Obje
by
Wingchild
·
· Score: 5, Insightful
From the article:
The Obje platform works with all standards, including those that have not yet been defined. It requires no central coordination, pre-configuring, or special set-up, and can be easily used by people with no technical expertise.
It provides users a way to combine devices to build simple solutions for hundreds of problems - easily assembling their particular applications from available devices and services. It offers manufacturers a simple, fast, and timely solution to the increasing requirement to connect products.
The Obje platform works with devices of all kinds - including cell phones, computers, personal digital assistants (PDAs), printers, set-top boxes, bar-code scanners, video displays, and others - from any manufacturer.
It works with everything, everywhere - because rather than being some kind of new l33t tech, or even a new technical standard, it's a self-described "meta standard".
In that respect, it reminds me a lot of Microsoft's DNA (Distributed Network Architecture), which I'm not sure anyone remembers. I only do because I built the Mid-Atlantic DNA labs, having worked for one of their Premiere Partners. Basically DNA wasn't new tech of any kind so much as a way of thinking and realignment of existing technologies. Instead of coming up with something really neat and whizbang to sell, Microsoft instead tried selling the process of how to think about how to get work done. Instead of creating apps that are live in the net, say, add a layer of firewalling and some abstraction between the user and the app itself, centralize all of your data in searchable SQL databases, and do other really common stuff!
And they charged people for it, too.:) Obje reminds me of this - standards about standards about actual work.
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.
Could be horribly insecure
by
moberry
·
· Score: 3, Interesting
Almost everyone knows that if it can be protected, it can be cracked. There could be horrible implications to this, just imagine sending actual code across a network. It will take some "1337" hacker just a couple of hours to crack the system wide open. And if he/she can send raw code to tell the network how its going to work, and tell the devices connected to it how they work. he/she could essentially control them a lot easier than todays more "traditional" methods.
Parc = Real PnP
by
SunCrushr
·
· Score: 5, Interesting
So from what I've read in the article, this looks to be Plug'n'play as it was meant to be:
Devices which use simple initial aggreed upon standard to extend their various servcies to each other without all the protocols having to be aggreed upon ahead of time, just a few simple initial protocols which are used to communicate and extend the other protocols and services between the devices. If this is applied correctly by the industry, it could change computing a lot, opening more complex systems to users with less experience and requiring less support resources. I'll be watching this closely.
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 Obje platform works with all standards, including those that have not yet been defined."
It's okay to be a optimistic about your product, but this is an all-time high...
Glad to see Jini getting some props
by
JohnnyCannuk
·
· Score: 4, Insightful
Glad to see PARC is using the idea of mobile code from Jini. The Jini Community has been doing this for over 5 years now. And it's not just for devices. Quite a few companies have used it as a platform for enterprise computing - in many ways it even competes with J2EE/EJB in this area.
Jini is a great Service Oriented Architecture (SOA) that is VERY secure yet still involves mobile code rather than just RPC calls.
It is a Java-based solution, but is opening up to other languages through the Surrogate Architecture...
Anyway, if we get excited about something new from PARC, we should investigate a fairly mature technology that it is built on top of.
If you think Obje is cool, check out RIO. Not just dynamic networking and mobile code, but dynamic provisioning and Quality of Service...
"Let's see.Net do that!":)
-- Never by hatred has hatred been appeased, only by kindness - the Buddha
Re:lpr -Pnewprinter
by
Linker3000
·
· Score: 3, Funny
To clarify...
One day I could walk in to my kitchen to discover that my kettle has become fed up with boiling water so it has explained the principle to the toaster which, due to limited processing ability has offloaded 'toasting' to the fridge.
Now, in order to cook breakfast, I fill the toaster with water and stick a filled coffee filter on top, put a couple of slices of white bread in the fridge, take some now-precooked sausages from the fridge and place them in the washing machine to keep warm, use my CD player to phone the local 'white goods realignment doctor' to book the kettle etc. in for a little chat, switch on the microwave oven to catch the breakfast news and go have a shave with my PDA while the coffee brews.
It seems like this offers a way of embedding the device's driver. - Just having the driver doesn't bypass any other security mechanisms already in place. Depending upon how it's used, it may not open any new security holes. Being able to just plugin the latest printer and have it work without installing any drivers is not a Bad Thing.
If Microsoft had "innovated" this we'ld be seeing printers being distributed with Windows binaries drivers in firmware, that only Windows machines could make use of. Coming from Parc, it will be available for multiple platforms but unfortuantely they're not making this an open standard.
<Paranoid Speculation>: Microsoft will copy the idea, but their standard will only communicate with Windows (and it's mobile derivatives) and give it away to hardware vendors. Free stuff from MS that will make your device truly PnP for 95% of computer users is an eash choice.</Paranoid Speculation>
--
--Aaron Greenberg
Active Networks - deja vu all over again
by
decoy999
·
· Score: 3, Interesting
More power to the network !!! Wunderbar ! What the active networks community has been trying to solicit for all these (well, not all that many) years.
Of course most fashionably cynical geeks obviously have strong opinions about "new" technologies (e.g. MDA etc. etc.) because they know everything that there is to know... right ?
I once read an article in Spectrum or something about degrees of ignorance (about not knowing something, or not even knowing that one doesn't even know and stuff) well all these meta-models are a little difficult to digest if you've spent the last 40 of the 50 or so yeas of the computer age reinventing and relabeling technologies over and over again and patting each other on the back.
Dammit, GUIs (ala windowing intfcs) haven't changed in 40 years, basic networking hasn't changed in 30 years... simply because un-insightful programmers heavily dependent on psuedo-geeky-techno-jargon-crap feeding idiots hype up brain dead hacks as "bleeding edge technology" (ever notice how happy we feel relabeling or re-"inventing" design patterns ?)
So of course, the lesser mortals who compare malicious viruses to mobile code, obviously don't appreciate the nuances of responsible meta-models. I think PARC has a good thing going. I wish them luck...hopefully Steve Jobs and/or Bill Gates will productize this one too:-)... and shame on you non-abstract thinking pseudo-geeks...
This sounds very much like PARC wants to teach machines how to interact more on "human" terms than on strict "computer" terms.
The most useful systems of tomorrow can't simply assume that peripherals/devices conform to their world view in order to work together. Instead, they must spend some time up front talking, listening, communicating, then eventually, cooperating.
Heading in this direction will prevent a technological monoculture from appearing, which wedges itself into a hole dug from its own presuppositions. Instead, I think this would foster a hardware equivalent of Open Source, where anyone who knew how to talk the fundamental protocol could build something interesting and introduce it into a system.
Of course, that's a pretty far-off idea, but I think it is worth pursuing.
Another PARC Invention? Who Will Steal It?
by
DoctorMabuse
·
· Score: 3, Funny
Dear PARC,
Thanks. We've gotten all we can out of mice, object-oriented languages, windows, laser printers and everything else we stole from you.
Sincerely,
Apple & Microsoft
You are so right
by
lokedhs
·
· Score: 4, Insightful
I remember being in the middle of all the Jini buzz a few years ago. I remember talking to some of the Jini designers, asking them for the API's I should use when talking to a distributed file storage service. I was under the impression (still am, actually) that such a service would be one of the first to be defined. It's easy enough, should just be a few interfaces. Could be designed in an hour.
Now, what was the reply? Something in the lines of: "it is not our job to define the standard API's. That's up to the community". Well, at that time I concluded that Jini would never succeed. And, it seems, Obje is falling into the same trap.
Protocols are needed. Regardless of wether they are defined in terms of binary data, XML schemas, or Java interfaces. You need them to be able to know what you are saying to the other party, and what it is trying to tell you.
I had some really neat ideas actually. I wanted to use stuff like distributed file storage. But there was no way I'd be writing my own interfaces that no one else would use. So, in the end, I didn't care much for Jini and apparently it was the right choice.
As far as I can tell, there is no difference between Obje and Jini, the designers are going to fall into the exact same trap. I would love it if someone showed me why Obje would succeed where Jini did not.
By the way, there were a lot of other things that sucked about Jini, but that had more to do with the crappy implementation than the actual concept.
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.
Slashdot Mirror
Personal Firewall and Anti-Virus coders everywhere today announced that "You've got to be kidding me".
This MUST either result in such intractable security issues that it will be worthless . . .
. . . or the machines will become sentient and use us (along with a form of fusion) as a plentiful power source.
Damn.
-Peter
Microsoft already has this patented feature in OE and IE.
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.
I simply can't imagine that this could be done in a secure fashion between any two arbitrary devices that don't know what the other is.
MS definatley has pior art on arbitrary code execution (I'm look at you, Outlook).
Religion is a gateway psychosis. -- Dave Foley
There is nothing wrong with generated code if you trust the sender. Plus if the code sent over the network is executed in a sandbox/jvm it shouldnt be incredibly risky (obviously a lot of potential for DoS attacks).
Code can be a very concise way to express an algorithm.
SURELY NOT!!!!!
Keep in mind I have only SkimmedTFA... This seems like it would be useful for forming ad hoc networks, for example in a disaster or emergency scenario. But for frequent daily use, it seems like it might be a particularly vulnerable protocol.
Are the benefits of high quality and reliable communication in a disaster/terrorism situation worth the potential risks of insecurity in that situation?
if you're sending code over the network in order to communicate, why have a traditional network at all? Why not just synchronize all the files between all the machines, or just have terminals? It seems like a mistake to send code for anything as a part of initiating network communication.
PC 1: "here's how to hack me."
PC 2: "OK! sending hack."
PC 1: "thanks! Now I'm hosed."
PC 2: "no prob. see you in hell! ha ha ha!"
stuff |
The propogation of code is worrisome, but I'm also unsure of the legal implications of allowing your code to accept the code and restrictions of others by automatically allowing it to run.
This may be a neat new way to logically propogate code, but once all the kinks are worked out it seems like it simply opens new doors for lawyers to battle out THEIR logic.
Brrrr
what is wrong with the existing protocol specs and RFCs? As it is, we have enough security problems even with a meticulous protocol specification. So making it more arbitrary will help? I doubt that, unless we are just willing to concede that security is a hopeless quest.
Microsoft has had technology for sending code over networks for years, as evidenced by the recent MSBlast worm :)
Essentially, it allows two devices to teach each other how to talk amongst themselves.
What happens if one of them starts to get a little verklempt?
Until Slashdot fixes the funny modifier, use insightful or interesting. The poster knows your intentions.
So, not an open standard. Well, back to SOAP...
The Army reading list
It does this by sending actual code over the network.
Nothin' to worry about here!
I "can'tse" any way this could develop into a security hole bigger than the goatse guy's famous anus.
This reverses years of tradition -- Microsoft is supposed to steal its "innovations" from from PARC, not the other way around.
And doesn't this sound like what goes way too wrong in Vernor Vinge's A Fire Upon the Deep, or an Iain Banks novel?
Opinions on the Twiddler2 hand-held keyboard?
From the article:
:) Obje reminds me of this - standards about standards about actual work.
The Obje platform works with all standards, including those that have not yet been defined. It requires no central coordination, pre-configuring, or special set-up, and can be easily used by people with no technical expertise.
It provides users a way to combine devices to build simple solutions for hundreds of problems - easily assembling their particular applications from available devices and services. It offers manufacturers a simple, fast, and timely solution to the increasing requirement to connect products.
The Obje platform works with devices of all kinds - including cell phones, computers, personal digital assistants (PDAs), printers, set-top boxes, bar-code scanners, video displays, and others - from any manufacturer.
It works with everything, everywhere - because rather than being some kind of new l33t tech, or even a new technical standard, it's a self-described "meta standard".
In that respect, it reminds me a lot of Microsoft's DNA (Distributed Network Architecture), which I'm not sure anyone remembers. I only do because I built the Mid-Atlantic DNA labs, having worked for one of their Premiere Partners. Basically DNA wasn't new tech of any kind so much as a way of thinking and realignment of existing technologies. Instead of coming up with something really neat and whizbang to sell, Microsoft instead tried selling the process of how to think about how to get work done. Instead of creating apps that are live in the net, say, add a layer of firewalling and some abstraction between the user and the app itself, centralize all of your data in searchable SQL databases, and do other really common stuff!
And they charged people for it, too.
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.
Almost everyone knows that if it can be protected, it can be cracked. There could be horrible implications to this, just imagine sending actual code across a network. It will take some "1337" hacker just a couple of hours to crack the system wide open. And if he/she can send raw code to tell the network how its going to work, and tell the devices connected to it how they work. he/she could essentially control them a lot easier than todays more "traditional" methods.
So from what I've read in the article, this looks to be Plug'n'play as it was meant to be:
Devices which use simple initial aggreed upon standard to extend their various servcies to each other without all the protocols having to be aggreed upon ahead of time, just a few simple initial protocols which are used to communicate and extend the other protocols and services between the devices. If this is applied correctly by the industry, it could change computing a lot, opening more complex systems to users with less experience and requiring less support resources. I'll be watching this closely.
"I see a device.... I can talk to it! Let's start out by identifying myself:"
COLOSSUS COLOSSUS COLOSSUS COLOSSUS COLOSSUS
(apologies to D.F. Jones)
1. Apple copies it into OSX
:)
2. Microsoft Copies Apples Implementation
3. Apple Sues Microsoft
4. PARC is clueless....
5. It becomes the de-facto standard in Windows...MS settles with Apple
Wait...did'nt this happen before?
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.
"The Obje platform works with all standards, including those that have not yet been defined."
It's okay to be a optimistic about your product, but this is an all-time high...
Glad to see PARC is using the idea of mobile code from Jini. The Jini Community has been doing this for over 5 years now. And it's not just for devices. Quite a few companies have used it as a platform for enterprise computing - in many ways it even competes with J2EE/EJB in this area.
.Net do that!" :)
Jini is a great Service Oriented Architecture (SOA) that is VERY secure yet still involves mobile code rather than just RPC calls.
It is a Java-based solution, but is opening up to other languages through the Surrogate Architecture...
Anyway, if we get excited about something new from PARC, we should investigate a fairly mature technology that it is built on top of.
If you think Obje is cool, check out RIO. Not just dynamic networking and mobile code, but dynamic provisioning and Quality of Service...
"Let's see
Never by hatred has hatred been appeased, only by kindness - the Buddha
To clarify...
One day I could walk in to my kitchen to discover that my kettle has become fed up with boiling water so it has explained the principle to the toaster which, due to limited processing ability has offloaded 'toasting' to the fridge.
Now, in order to cook breakfast, I fill the toaster with water and stick a filled coffee filter on top, put a couple of slices of white bread in the fridge, take some now-precooked sausages from the fridge and place them in the washing machine to keep warm, use my CD player to phone the local 'white goods realignment doctor' to book the kettle etc. in for a little chat, switch on the microwave oven to catch the breakfast news and go have a shave with my PDA while the coffee brews.
Is that it?
AT&ROFLMAO
It seems like this offers a way of embedding the device's driver. - Just having the driver doesn't bypass any other security mechanisms already in place. Depending upon how it's used, it may not open any new security holes. Being able to just plugin the latest printer and have it work without installing any drivers is not a Bad Thing.
If Microsoft had "innovated" this we'ld be seeing printers being distributed with Windows binaries drivers in firmware, that only Windows machines could make use of. Coming from Parc, it will be available for multiple platforms but unfortuantely they're not making this an open standard.
<Paranoid Speculation>: Microsoft will copy the idea, but their standard will only communicate with Windows (and it's mobile derivatives) and give it away to hardware vendors. Free stuff from MS that will make your device truly PnP for 95% of computer users is an eash choice.</Paranoid Speculation>
--Aaron Greenberg
More power to the network !!! Wunderbar ! What the active networks community has been trying to solicit for all these (well, not all that many) years.
... right ?
... simply because un-insightful programmers heavily dependent on psuedo-geeky-techno-jargon-crap feeding idiots hype up brain dead hacks as "bleeding edge technology" (ever notice how happy we feel relabeling or re-"inventing" design patterns ?)
:-) ... and shame on you non-abstract thinking pseudo-geeks ...
Of course most fashionably cynical geeks obviously have strong opinions about "new" technologies (e.g. MDA etc. etc.) because they know everything that there is to know
I once read an article in Spectrum or something about degrees of ignorance (about not knowing something, or not even knowing that one doesn't even know and stuff) well all these meta-models are a little difficult to digest if you've spent the last 40 of the 50 or so yeas of the computer age reinventing and relabeling technologies over and over again and patting each other on the back.
Dammit, GUIs (ala windowing intfcs) haven't changed in 40 years, basic networking hasn't changed in 30 years
So of course, the lesser mortals who compare malicious viruses to mobile code, obviously don't appreciate the nuances of responsible meta-models. I think PARC has a good thing going. I wish them luck...hopefully Steve Jobs and/or Bill Gates will productize this one too
Reference the Amiga Computer and its use of Autoconfig, before windows attempted their version with "plug and pray."
God, I miss that machine.
A couple of examples:
Smalltalk - took "everything is an object" to the extreme. Smalltalk's byte-coded portability worked, in 1980.
CLOS - its "meta-object protocol" lets developers change the language's object-model semantics.
To a Lisp hacker, XML is S-expressions in drag.
This sounds very much like PARC wants to teach machines how to interact more on "human" terms than on strict "computer" terms.
The most useful systems of tomorrow can't simply assume that peripherals/devices conform to their world view in order to work together. Instead, they must spend some time up front talking, listening, communicating, then eventually, cooperating.
Heading in this direction will prevent a technological monoculture from appearing, which wedges itself into a hole dug from its own presuppositions. Instead, I think this would foster a hardware equivalent of Open Source, where anyone who knew how to talk the fundamental protocol could build something interesting and introduce it into a system.
Of course, that's a pretty far-off idea, but I think it is worth pursuing.
Dear PARC,
Thanks. We've gotten all we can out of mice, object-oriented languages, windows, laser printers and everything else we stole from you.
Sincerely,
Apple & Microsoft
Now, what was the reply? Something in the lines of: "it is not our job to define the standard API's. That's up to the community". Well, at that time I concluded that Jini would never succeed. And, it seems, Obje is falling into the same trap.
Protocols are needed. Regardless of wether they are defined in terms of binary data, XML schemas, or Java interfaces. You need them to be able to know what you are saying to the other party, and what it is trying to tell you.
I had some really neat ideas actually. I wanted to use stuff like distributed file storage. But there was no way I'd be writing my own interfaces that no one else would use. So, in the end, I didn't care much for Jini and apparently it was the right choice.
As far as I can tell, there is no difference between Obje and Jini, the designers are going to fall into the exact same trap. I would love it if someone showed me why Obje would succeed where Jini did not.
By the way, there were a lot of other things that sucked about Jini, but that had more to do with the crappy implementation than the actual concept.
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.