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."
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
Anonymous Coward
·
· Score: 1, Insightful
And how you can do something useful, like access the hardware through "sandbox"?
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.'"
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?
Re:First thoughts...
by
jd
·
· Score: 2, Insightful
More likely, it'd be used in some of the more mission-critical heterogenius networks, where you can't afford any outage for any length of time.
Such networks would likely be physically private networks, or otherwise on a secure LAN. Nobody puts mission-critical stuff over an unsecure, fragile backbone such as the Internet. Well, other than the US Government.
-- It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Sounds Like Sun's JINI
by
Anonymous Coward
·
· Score: 1, Insightful
How is this different that Sun's JINI?
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.
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.
Re:How to use it?
by
standard+method
·
· Score: 2, Insightful
Q. How much did it cost to make it?
Seriously though. I don't think this was made by someone with just a shoestring budget and a desire to help computer-kind. Not that they're doing their work for the wrong reasons, but if this project cost them a lot of money, offering it for free in an Open Source fashion is going to mean.. they're out of a lot of money.
Just a thought, thought it's probably not the most popular one on the block.
-- "I'll be a killer whale, when I grow up" -Wintersleep
Re:How to use it?
by
PyromanFO
·
· Score: 2, Insightful
How do you expect CS researches to make money if they don't charge for their work? Maybe you can create really good knock-offs and implementations of standards using the promise of some vague support contracts to entice companies and the spare hours of out-of-work coders, but when will that actually create something?
Charging for your work and restricting access to your code are two entirely different things. I don't know about you, but as a software developer I am worth much more to my boss than simply my code. PARC could make money without restricting access to the code. For instance, having companies pay them to teach their driver writers how to use this new tech. PARC has the knowledge, which is worth much more than the code itself.
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:Whats wrong with generated code?
by
dsojourner
·
· Score: 2, Insightful
The problem is you're permitting coding of your network interface... even assuming your "sandbox" holds up, it would seem there's ample room for a denial of service.
"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...
Sending actual code over a network?
by
Anonymous Coward
·
· Score: 1, Insightful
...sounds like downloading nightly builds from a CVS to me.
/has rtfa but everything else was already said
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.
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
dont touch until it is mature
by
Dr.Knackerator
·
· Score: 2, Insightful
lets hope the underlying VM interpreter (or whatever) is shared source of some kind.
otherwise can you imagine the random problems you are going to get when one of the devices has a problem with different VM implementation. Or security issues on individual VMs?
It took a good while to get the various flavours of Java VMs to all work pretty much the same, the same would be true here.
If anyone can get this right, it'll be PARC...
by
alispguru
·
· Score: 4, Insightful
PARC has a history of doing things meta before anyone else, and by and large getting it right.
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.
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.
We'll view Viruses with nostalgia
by
Gr8Apes
·
· Score: 2, Insightful
when the first round of this tech is widely adopted and hacked. Something about it sounds just too good to be true... and you know that adage - it generally is. It'll definitely be too good for the first hacker to figure it out.
If two sides can communicate well enough to teach eachother a third language, wouldn't they be able to communicate, period?
And if you need to install software on either end so they can go through this teaching process, isn't it easier to just install a TCP/IP stack on both ends?
ok, off to read the article...
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.
That is a bizzare statement
by
autopr0n
·
· Score: 2, Insightful
Charging for your work and restricting access to your code are two entirely different things. I don't know about you, but as a software developer I am worth much more to my boss than simply my code.
If your boss needs to keep you around in order to use the software, it's obviously not that good. Good software should, for the most part, be able run given easy to understand instructions, and be easy to maintain by any competent programmer. I'm not against giving away source code by any means, but when people do give away code, it's a gift, not an obligation.
Slashdot Mirror
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.
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?
How is this different that Sun's JINI?
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.
So, not an open standard. Well, back to SOAP...
The Army reading list
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.
The problem is you're permitting coding of your network interface ... even assuming your "sandbox" holds up, it would seem there's ample room for a denial of service.
dsojourner
"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...
...sounds like downloading nightly builds from a CVS to me.
/has rtfa but everything else was already said
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.
2 1337 4 u!
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
lets hope the underlying VM interpreter (or whatever) is shared source of some kind.
otherwise can you imagine the random problems you are going to get when one of the devices has a problem with different VM implementation. Or security issues on individual VMs?
It took a good while to get the various flavours of Java VMs to all work pretty much the same, the same would be true here.
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.
when the first round of this tech is widely adopted and hacked. Something about it sounds just too good to be true... and you know that adage - it generally is. It'll definitely be too good for the first hacker to figure it out.
The cesspool just got a check and balance.
(I didn't read the article yet.)
If two sides can communicate well enough to teach eachother a third language, wouldn't they be able to communicate, period?
And if you need to install software on either end so they can go through this teaching process, isn't it easier to just install a TCP/IP stack on both ends?
ok, off to read the article...
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.
Charging for your work and restricting access to your code are two entirely different things. I don't know about you, but as a software developer I am worth much more to my boss than simply my code.
If your boss needs to keep you around in order to use the software, it's obviously not that good. Good software should, for the most part, be able run given easy to understand instructions, and be easy to maintain by any competent programmer. I'm not against giving away source code by any means, but when people do give away code, it's a gift, not an obligation.
autopr0n is like, down and stuff.