PARC's New Networking Architecture

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."

Comments

In related news..

[ebob9]

Personal Firewall and Anti-Virus coders everywhere today announced that "You've got to be kidding me".

Re:In related news..

[CountBrass]

That was my reaction to.

And then I remembered a previous slashdot story pointing to an article about various 1337 virus writers and I remembered that they were all so proud that they used VB.

Re:In related news..

[ScrewMaster]

No problem ... just make sure that "autopreview" is turned off.

Only two possible outcomes.

[pete-classic]

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

Re:Only two possible outcomes.

[Dachannien]

About 34 years too late.

Re:Only two possible outcomes.

[plams]

...or someone will find out how to run linux on them and make a beowulf cluster.

Re:Only two possible outcomes.

[Frymaster]

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.

Re:Only two possible outcomes.

[Anonymous Coward]

note that parc is no longer part of xerox corp, xerox happens to be one of their many funders now

Re:Only two possible outcomes.

[the_duke_of_hazzard]

I'm not sure as to the use of this for general computing, but I can see the virtue of this for things like TV Set Top Boxes, which routinely download applications/middleware/OSes from the broadcast stream/cable.

If you trust the source and the network is secure, what's the problem? It's as safe as running an exe on your windows box...

Re:Only two possible outcomes.

[autopr0n]

This MUST either result in such intractable security issues that it will be worthless . . .

Yup, just like java applets and flash.

Re:Only two possible outcomes.

[sketerpot]

Well, they do have that bit at the bottom about "licensing". I quote:

PARC is seeking corporate partners interested in leveraging the Obje platform inside their own products and applications. To learn more, please contact Hermann Calabria, Business Development, 650-812-4751.

I hope it doesn't wither and die.

Re:Only two possible outcomes.

[mattyrobinson69]

YEAH!!! beowulf cluster of printers and other periferals

Sorry

[Anonymous Coward]

Microsoft already has this patented feature in OE and IE.

Re:Sorry

[AndroidCat]

I hear that some virus writers will be suing for co-ownership of that patent. "It was a collaboration", they say. Microsoft denies this: "We set it up as 'open software' so that anyone could have done it."

RTFA before replying - oh wait, you can't -

[Wingchild]

because the real link is here. The one supplied in the story 404'd on me.

Thanks, Google!

Re:RTFA before replying - oh wait, you can't -

[Anonymous Coward]

Both the supplied URL and your URL work. Don't know why you'd get a 404.

Sun already tried this

[kroekle]

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

[JBMcB]

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.

Re:Sun already tried this

[Anonymous Coward]

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.


Jini was agreat idea killed by Sun's determination to ignore anything other than Java.

Re:Sun already tried this

[NSash]

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.

Re:Sun already tried this

[tommasz]

I've always thought the discovery part of Jini was the only thing of great value in it. Having devices discover each other without blanketing the network (wired or wireless) with messages is a great feature. Apple's Rendezvous does this, and does it so well you don't even notice it, services just appear in Safari and iTunes. If Obje can do that too, that's nice, but is it in any way revolutionary? I doubt mDNSResponder is that hard to implement, even in a handheld.

Re:Sun already tried this

[deanj]

Cisco uses Jini for some of it's products/projects (notably, Spanish Inquistion), as do other companies.

Re:Sun already tried this

[JohnnyCannuk]

Jini is a java based distibuted computing platform dumbass...it IS Java.

Re:Sun already tried this

[Anonymous Coward]

Jini was agreat idea killed by Sun's determination to ignore anything other than Java.

Jini is still alive, but its adoption was severely hindered by Sun's marketing that implied it was a devices-only product at a time when Sun did not have a small-footprint JVM that could host it on most devices. Doh!!!

Re:Sun already tried this

[MountainLogic]

My Other Computer Is A Data General Nova III.

Boy that sends me back. I can still remember the octal you needed to enter on the front panel of our Nova to boot it. I miss the days of floppies big enough to use for place mats and paper tape.

Re:Sun already tried this

[Anonymous Coward]

Sounds a bit like OpenFirmware. Plug a card into the computer, and the firmware pulls the cards driver from the cards ROM as Forth P-Code.

Parent should be "Insightful," not "Funny"

[Anonymous Coward]

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"

[drinkypoo]

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.

Re:Parent should be "Insightful," not "Funny"

[Short Circuit]

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"

[jilles]

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.

Re:Parent should be "Insightful," not "Funny"

[BlueTooth]

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.

Re:Parent should be "Insightful," not "Funny"

[goatwhip]

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"

[Anonymous Coward]

And how you can do something useful, like access the hardware through "sandbox"?

Re:Parent should be "Insightful," not "Funny"

[JohnnyCannuk]

Uhm, try going here and see how "dead" Jini is...

'Cuz it's not. Not even close

Re:Parent should be "Insightful," not "Funny"

[drinkypoo]

Or I could be implying that with a little additional thought, they'd find the answer. It doesn't make them stupid, it means they're thinking along different lines.

There are numerous methods for detecting when code is trying to do things it's not allowed to do. Many of them are built into some of our favorite operating systems already. Other features which are just coming to PCs, like execution protection, will make this even easier.

Re:Parent should be "Insightful," not "Funny"

[jd]

"Treats you accordingly"...

So, if you're a spammer or a virus writer, it does an X-Files and reprograms an SDI-era space-based laser cannon to blast your computer to pieces...?

Hmmm. You've still got the problem that you should never hit reply to a spam mail.

Re:Parent should be "Insightful," not "Funny"

[Anonymous Coward]

It's "simple" because it's well known. Do a google search and you'll be able to find plenty of systems that transfer (interpreted, not machine) code across a network.

Re:Parent should be "Insightful," not "Funny"

[Junior J. Junior III]

Since this is Xerox that's developing the technology, I'll start worrying about it in about 20 years.

Re:Parent should be "Insightful," not "Funny"

[Anonymous Coward]

Perl supports "tainting" of data, so you don't do accidentally anything stupid with information that isn't secure.

Define "anything stupid".

A network connection that happens to use up a lot of battery power on a mobile device would consider transmission of a lot of data to be "something stupid". The exact same type of connection in an Intranet environment would be commonplace.

Given that you can't describe all properties of an arbitrary network before it is designed, there is no way of coding a routine to decide whether something is "stupid" in advance.

Re:Parent should be "Insightful," not "Funny"

[The Spoonman]

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.

Re:Parent should be "Insightful," not "Funny"

[b0z0mind]

This is currently being done using Jini 2.0! It provides two types of security: method level authentication/authorization and communications level using SSL/Kerberos/etc. Downside: out of the box requires Java for the mobile code features to work. Vendors such as PsiNaptic provide C code implementations for a price :-)

Re:Parent should be "Insightful," not "Funny"

[Anonymous Coward]

Simply enough, you don't trust the other end, and all code is run in a sandbox.

So it can only take control of how you talk on that bus. This can still be a problem.

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.

That only matters if you've got holes in your sandbox, and in that case this isn't good enough. If the device can send stuff fast enough to DoS some part of the machine, you'd better leave out the "strange" bit.

Re:Parent should be "Insightful," not "Funny"

[addaon]

I find that the categorization I use most often when I meet new people these days is how they respond to 'feeling stupid.' A person can either get frustrated and walk off in a huff, or feel motivated to learn more. I get the sense you are currently in the first category; you will not only be smarter, but probably lead a more fulfilling life, if you manage to move into the second.

Re:Parent should be "Insightful," not "Funny"

[logicnazi]

It seems like this is your problem not theirs.

Apparently you know that the common usage of 'simple' or 'obviously' is "straightforward to a expert in that area" so why would it bother you.

These kinds of complaints are like L.A. banning using the term 'master/slave' wherein common usage is demanded to change because a few people are offended.

The loss of productivity and the sheer annoyance of changing our words so that some people who *delibrately* misinterpret the words (after all since you are complaining about it I can only assume you know that people aren't really using 'obvious' to mean 'obvious') can feel better outweight any benefit in terms of hurt feelings.

Re:Parent should be "Insightful," not "Funny"

[blamanj]

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"

[cthrall]

If you use digital signatures and a third-party certificate authority that is universally trusted, you can hit the hardware via JNI.

Digital signatures can be a pain, but once you get them into an automated process and get everything working you've got a trusted, reliable system.

Re:Parent should be "Insightful," not "Funny"

[DA-MAN]

Since this is Xerox that's developing the technology, I'll start worrying about it in about 20 years.

You mean after Apple clones it, then Microsoft clones it, then Apple sues Microsoft for cloning the Apple implementation?

Yeah 20 years seems about right.... Eventually the biggest complaint for the Apple one will be that the nic has only one blinking light, while the Microsoft has two. Then there will be an after market second blinking light for the Apple version that the Apple zealots will point to.

Re:Parent should be "Insightful," not "Funny"

[Short Circuit]

"Stupid" as in anything relating to immediate system security and integrity. It won't let you directly write the data to disk, for instance, without first laundering the data. Of course, by laundering the data, you're only telling Perl that the programmer thinks it's safe. That still doesn't mean the data is safe.

Re:Parent should be "Insightful," not "Funny"

[michael_cain]

With Java you can do this. Just run the code in a sandbox.

Java is a good example, although it's feasible with most any decent interpreted language. The interpreter can (and should) enforce whatever restrictions are necessary to reflect the degree of trust. I have a software patent (I know, that makes me a bad person :^)) for an architecture for consumer devices attached to the cable network to execute device-specific proxy code on a headend server in a secure fashion in order to allow users access to their devices from the Internet. I did the proof-of-concept system in Java.

Re:Parent should be "Insightful," not "Funny"

[autopr0n]

What portion of detecting whether code sent to you over the network is doing something 'strange', do you find simple?

The part where you limit access to any APIs that could be dangerious, and run it in a sandbox so that it can't get creative on it's own.

Re:Parent should be "Insightful," not "Funny"

[drinkypoo]

Ideally the process which handles communication would be in user space and the processes which utilize it would gracefully handle its demise and return, thus the effect of such a problem would be minimal.

Re:Parent should be "Insightful," not "Funny"

[cubic6]

It works for Java applets, but what the article discusses is a whole nother matter. The sandbox that Java applets run under is very restrictive. If they can come up with a suitable sandbox that allows devices to run transmitted code and be able to do something useful, that's great. However, since this deals with hardware configuration, you have to give the code access to the actual hardware. That's a big security no-no. Once you have access to the hardware, you can do all sorts of nasty things.

I'm not saying this is impossible, but it'll be far harder than the Java applets that you give as an example of how easy it is. It's also worth noting that the article doesn't talk about a VM or any kind of concrete details, presumably because they hope to sell it.

Re:Parent should be "Insightful," not "Funny"

[jdray]

However, since this deals with hardware configuration, you have to give the code access to the actual hardware.

Okay, so I don't necessarily disagree with you, but I didn't really get that out of the paper. It seemed to me that the idea (and at this point, that's about all they've got) is to exchange capabilities for communication. So, component A send code to component B to tell B how to talk to A, including new capabilities that A hadn't necessarily thought about. This doesn't necessarily compromise A or any of its peripherals, but gives it instructions for building a conduit to B. It can do what it wants with the code, but it should be able to be successful at constructing a conduit without loading the code into its innards.

Now, having said that, I'll offer that I often don't have a clue what I'm talking about. Being a Slashdotter, though, that doesn't stop me from posting.

Re:Parent should be "Insightful," not "Funny"

[sketerpot]

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."

Please oh please tell me that you capitalized "basic" for emphasis, and you don't mean a device driver written in BASIC. *cower*

Re:Parent should be "Insightful," not "Funny"

[blamanj]

True it's harder, but not impossible. You just have to be creative about the security. With Java, you can do very fine grained security, e.g., read access to this directory plus write access to a single file. It's not necessarily easy, but it isn't as horrible as a lot of people seemed to be claiming.

Presumably, with this, you'd have security descriptors like 'you get access to this port but only for so many minutes with a limit of N bytes transmitted'. Give the security descriptors expiration times to prevent them from being forged, etc.

Re:Parent should be "Insightful," not "Funny"

[sketerpot]

You should remember that Java "the language" and Java "the platform" are different things, and can be used seperately. For example, Python on the Java VM = Jython.

Re:Parent should be "Insightful," not "Funny"

[Bob Davis, Retired]

You know, they DO have multisession CDs now. You could earmark one CD as the 'Driver CD' and not waste so many.

Re:Parent should be "Insightful," not "Funny"

[jilles]

I know SUN is still pushing it with some moderate success but it hardly is the thing it was hyped to be five years ago (and IMHO never will).

Re:Parent should be "Insightful," not "Funny"

[Synonymous Yellowbel]

Or use a rewritable...

Re:Parent should be "Insightful," not "Funny"

[drinkypoo]

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.

Re:Parent should be "Insightful," not "Funny"

[drinkypoo]

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 :)

Re:Parent should be "Insightful," not "Funny"

[The Spoonman]

Nope, I meant basic as in functionality, not basic as in gorillas tossing bananas. ;)

Re:Parent should be "Insightful," not "Funny"

[The Spoonman]

You know, not every drive can read multisessions properly. And in reply to the reply to yours, they can't all read rewritables, either. Grabbing a basic driver from firmware's just another driver on the OS. Shouldn't matter how old the PC is.

Re:Parent should be "Insightful," not "Funny"

[stephanruby]

By that definition, any new-fangled technology that has been overly hyped by marketing is now DEAD.

Re:Parent should be "Insightful," not "Funny"

[tylernt]

Intel drivers drive me nuts too. However if you are clever you can drill down 12 levels of folders and find the .inf and .dll files that are the actual driver, and just put those on a floppy. Way less than 1.44MB. Intel drivers seem to be pretty universal so you can just do this once and your floppy will work on several flavors on Intel NICs.

Re:Parent should be "Insightful," not "Funny"

[Rysc]

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.

OpenfirmWare+BIOS-level networking+maybe some little addons.

Yawn.

Re:Parent should be "Insightful," not "Funny"

[richie2000]

Nope, I meant basic as in functionality, not basic as in gorillas tossing bananas. ;)

I sometimes do the one-man-wave of the victorious gorilla just to see if people I talk to are geeks or just posers. Wait, results just in: They're all posers! You however, are a true geek. *bows*

Re:Parent should be "Insightful," not "Funny"

[The Spoonman]

Yeah, I learned this trick a little while ago. It seems HP drivers are similarly setup. You can often find their drivers buried within the 35M of fluff you need to download. Of course, if I were a home user on a dial-up, I'd still be more than a little pissed...

Re:Parent should be "Insightful," not "Funny"

[Bob Davis, Retired]

Actually, almost every CD-ROM drive built can read multisession CDs. Chances are, if your CD-ROM drive doesn't have a carrier, it can read multisession CDs.

If you have a CD-ROM with a carrier that still works, congratulations. I'll trade you a fully functional IDE CD-ROM (multisession capable) for it if you include at least one carrier with the drive!

Atleast we know they can't patent it.

[Monkelectric]

MS definatley has pior art on arbitrary code execution (I'm look at you, Outlook).

Not enough info ....

[IamGarageGuy 2]

I'm sort of bummed that all the stuff I knew about the seven layers of networking is going to be moot eventually, but all the studying of virii and attacks will become more useful.

Re:Not enough info ....

[sjwt]

you meen the OSI theoretical 7 layer model
that IIRC no one had got working past 6 layers..

mind you it was many moons ago when i was last
requested to becoem infomed on the 7 layer model,
NT 4 was moving in on novel and id just herd of
a new apprently working version of windows comeing out around 2000..

so most of what i lernt back then was moot :)

Re:Not enough info ....

[Anonymous Coward]

...but all the studying of virii and attacks will become more useful.

The plural of "Virus"

Whats wrong with generated code?

[SkunkPussy]

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.

Re:Whats wrong with generated code?

[NSash]

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?

[stevesliva]

Please moderate parent as "Extremely annoying sig


"

Re:Whats wrong with generated code?

[crmartin]

Code is much nicer. You should try it.

Re:Whats wrong with generated code?

[dsojourner]

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

Re:Whats wrong with generated code?

[scambaiter]

hum, sandbox. I thought this was like "plug in printer, printer announces itself to any machine connected and sends (if needed) drivers to the machine". Could this really work out in a sandbox for the whole variety of stuff you could connect to a computer?

Re:Whats wrong with generated code?

[GileadGreene]

And to think that all this time, I was expressing my algorithms in pictograms!

Yeah, pretty much everyone seems to use UML these days...

Re:Whats wrong with generated code?

[sir_cello]

This is the crux of the problem: any language is ultimately at risk of subversion if it is not sandboxed properly. For real security: virtual machines are the way to go: this is what granular processes offer, but something finer is required to make it work properly.

Re:Whats wrong with generated code?

[autopr0n]

Code can be a very concise way to express an algorithm.

Damnit, you're right! Now what the hell am I going to do with all this Turing machine tape!?

First thoughts...

[trickofperspective]

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...

[Wingchild]

... what article were you reading? The article doesn't talk at *all* about letting devices communicate independantly and learn to talk to each other.

It provides a `standard` that `allows` such communications to, in theory, take place. It does it by removing some of the intelligence apps currently have to have in order to talk, so long as you adhere to the standard. But it's not like they're inventing new protocols here.

If TCP/IP is a vast highway to transfer information, Obje is a new kind of tire.

Re:First thoughts...

[trickofperspective]

I see the point you're making, in that the tech (if it works) doesn't specifically create ad hoc networks... but as you point out yourself:

It provides a `standard` that `allows` such communications to, in theory, take place.

Which goes right along with my idea that it would "would be useful for forming ad hoc networks." And particularly useful in a situation where one would desire to link various and diverse forms of media and communication.

-Trick

Re:First thoughts...

[jd]

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.

Sounds Like Sun's JINI

[Anonymous Coward]

How is this different that Sun's JINI?

Re:Sounds Like Sun's JINI

[Anonymous Coward]

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:Sounds Like Sun's JINI

[JohnnyCannuk]

Jini defines APIs for printers and cameras;

So, what your saying is they have never read the Jini spec or decided to find out what Jini is then?

Hint: It has nothing to do with "printers" and "cameras" and everything to do with "services" - any services.

I do a little development in Jini and I can tell you, Jini does EVERYTHING Obje does...

Re:Sounds Like Sun's JINI

[110010001000]

In other words, those other technologies are designed to work with real devices that people may actually want to use.

Our technology on the other hand works great in the lab! Another grant please.

Re:Sounds Like Sun's JINI

[Anonymous Coward]

I think you're being a bit generous to them - it sounds like they're willfully misrepresenting JINI.

I think they'll suffer from the same "a priori knowledge" problem that JINI does - sure you can find a service (even one of a type you didn't know about when you were compiled) and get a little program that lets you interact with that service (talk to it, call its functions, turn parts of it on or off, etc) but the trick is to know what that stuff _means_ (I think the AI boys would say "lacks a shared ontology" or something). It's very hard to meaningfully call a method when you've got no idea what the method does.

In a few cases you can show the received information in some kind of "service browser" or some other UI, and let a person (who hopefully does share an ontology with the program's author) figure out what to do. In circumstances where that's not appropriate, you end up having to overlay some system of understanding (like a "printer" definition) so that programs can do something meaningful with it.

This is one serious place where the common practice in Open Standards has been a consistent let-down - everyone is shy about stomping around defining stuff, instead leaving it to some standards body (which often doesn't exist, doesn't understand, or just doesn't care). Microsoft, on the other hand, are perfectly happy to define the requisite schemas, ontologies, and taxonomies, and impose them on everyone else - and the device/network manufacturers go along with this because they want anything that works.

Re:Sounds Like Sun's JINI

[wonderman]

Only if you are thinking at the implementation level to you consider
that applications must agree on interfaces. The notions that Obje
imply in the article indicate things that Jini can do too.

The downloaded code from a Jini service registration is just a simple
agreement. It is just some code. It might talk, via a protocol,
back to the other end to provide method call level ontologies. Why
would you possibly think that this is the only remote capabilities
of Java or of the Jini platform?

The downloaded code can do anything you program it to do. It can
provide the same sort of reflective interface that Obje implies. Obje
looks like a media based discovery mechanism. If I am an Obje entity
that can display graphics, then what am I to do with a modbus device
that shows the status of 10 switches? Will I know how to read the
values of those switches and draw pictures depicting the switch position?
Will I know that the switches are dip switches or toggle switches?
Will I have all the knowledge to draw such imagery with orientation?

What if the modbus device sent me the code to do the rendering? What
if the deployer of the modbus device didn't want to pay for the extra
memory to show the switch imagery on the display?

How will Obje make it possible for this to still work? The answer is
that its not magic! So, it can't work no matter what! There will be
some preconditions and ontologies that must exist. Jini can provide the
same, but Jini can perhaps go beyond by providing integration services.

In Jini, I could deploy a second service which has a ServiceUI
that provides the rendering capabilities for drawing the switches how
I wanted them to be. I could then configure my display service to know
about that new service too. now I have a working solution. I didn't
have the manufacturer of the modbus device provide the solution and I
didn't have to have the manufacturer of the display provide the solution.

I could integrate it myself (one of Obje claims) and I got exactly what
I needed!

Re:Sounds Like Sun's JINI

[Anonymous Coward]

About that 'misrepresenting' bullshit. The main person involved -Keith Edwards- he's the guy who wrote the book 'core jini'.

So, he should know if all they are doing is reimplement Jini.

Re:Sounds Like Sun's JINI

[lokedhs]

I have that book in my bookshelf. I did read it when it came out. It was after I had read the book I concluded that Jini wouldn't work.

Apparently it's better now, but in the 1.0 version you had to write (or copy&paste) a hundred or so lines of boilerplate code, and the deployment model was an extreme pain. The description on how to create the Hello World service is 24 pages! And that is after 120 or so pages of theoretical discussion. Why the designers of Jini (or at the very least, the authour of the book) didn't provide some helpers to do this is beyond me.

I just wanted you to know about what it's like to read his work. Now, it's not just his fault, it's the Jini designers fault too, but he certainly was an advocate for the technology in the book.

Why even have a network?

[192939495969798999]

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?

[truthsearch]

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.

Re:Why even have a network?

[parksie]

The code that's sent doesn't necessarily need to be run on the host CPU.

It could be nothing more excessive than a .ppd file for a PostScript printer's interpreter.

DMCA and other viruses

[buckhead_buddy]

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

Re:DMCA and other viruses

[CountBrass]

No problem if all the code is GPL'd...

Re:DMCA and other viruses

[Anonymous Coward]

The next innovation from PARC will thus be a legal document analyzer. This analyzer will verify compatibility between licenses of varying devices and/or their network code. Once a collision is found, it will automatically report the offense to Microsoft's DRM Security Office and to the RIAA. They, in turn, will sue everybody, after patenting and copyrighting all possible forms of the alleged legal violation and the services related thereto.

Of course, when a new device receives the network code from Obje, it will have to sign on the bottom line of the object code... in triplets.

Re:DMCA and other viruses

[socode]

Is the device that sends the code also going to open an FTP server from which you can download the source?

that's stupid

[Anonymous Coward]

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.

Re:that's stupid

[Anonymous Coward]

This might aid security instead of making it worse. By having a regulated framework in which to add new protocols (note that protocols can be signed!), one would certainly avoid building new protocols on top of existing ones. As is done now, ie why would you think that a homemade protocol on top of HTTP (or SSH or SSL or what have you) would be more secure? Some times it is better to make a new one. Oh, and remember that deciding whether two independantly secure protocols still are secure when combined, that's in NP!

Prior art

[ThePyro]

Microsoft has had technology for sending code over networks for years, as evidenced by the recent MSBlast worm :)

Bah-brah

[illuminata]

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?

How to use it?

[tcopeland]

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.

So, not an open standard. Well, back to SOAP...

Re:How to use it?

[standard method]

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.

Re:How to use it?

[tcopeland]

> offering it for free in an Open Source
> fashion is going to mean.. they're out of a
> lot of money.

Hm, maybe, but if they're hoping to spread a new standard for communicating between devices, publishing it so folks can implement/analyze/understand it might be a better way to go.

To me it's as if they're saying "we've invented something very nifty, please give us some money and we'll show it to you". It's just hard to make a compelling argument that way. Or maybe I'm missing some point in their pitch...

Re:How to use it?

[bentini]

Typical geek complaint: "Oh poor PARC, they lost the war by not selling what they did in a meaningful way! If only they had championed the PC, we wouldn't have M$ today."

So, PARC does something about this, and we still hate them. 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?

Re:How to use it?

[Short Circuit]

Unless, of course, they kept it in-house a long time before announcing it.

If they spent enough time studying it to learn its implications, they could license that instead of the underlying technology. So long as they stayed away from patents, and only protected their IP through contracts.

Re:How to use it?

[standard method]

Oh, I know what you mean, I had kind of a similar thought when I read the end of the article, but my point remains the same. For understanding the idea, it's great for "the community" to get a hold of the code, but that's ignoring the fact that this is a company, and a company that researches for a living. (Keep in mind this post isn't designed to shoot you down or anything, more of a clarification of my own points.) These people do research on stuff exactly like this, and the reason that this story was actually notable was because this is at least semi-revolutionary. It's something noteworthy, because time/money/effort was put into this project, and none of those things are free. Particularly not the middle quotient.

1: Research
2: Open Source your results
3: No profit!

Of course, profit is evil, because it represents the minimization of freedom, money is bad, etc etc.. But I would think that not making any money on things like this, or at the very least not breaking even, would kind of hamper future developments. Yes, there are research grants, etc, but are they enough?

And, the possibility that I am in fact quite wrong is very likely. So. I've just showed you!

... Yeah.

Re:How to use it?

[tcopeland]

> 1: Research
> 2: Open Source your results
> 3: No profit!

standard_method invokes 3-Steps-To-Profit! tcopeland counters with Obligatory-Simpsons!

The problem, I think, is that it might be revolutionary... or maybe it's not. It's hard to tell, since I can't read much about it other than meta-interfaces. It'd be fine if they have a closed-source implementation or some such... but not even knowing what the public interfaces are makes it hard to get a handle on it.

I guess it's the broad, sweeping nature of the announcement. I mean, if they announced "we've got a great new way for a shipping company to track container delivery", sure, fine, let Evergreen contact them and give them money if they've got a track record in that market. But to say "we've invented a wonderful new way of communicating between devices, now pay us to tell you about it", well, there are a lot more players in that field and people are working on those rather tricky problems all the time.

On the other hand, I could be mad. Mad, I say!

Re:How to use it?

[standard method]

I say... mad.

But, you have a good point about the "broad, sweeping nature of the announcement." It's kind of like someone saying they just invented computers.

"Now, would any business like to contact us for giving us large sacks of cash in exchange for this new wonderful technology?"
Cue the fine print:"You're gonna have to figure out what to do with it yourself though."

Not that I'm saying this is the magnitude of the "invention" of the computer. But. Well. I was going to say "but you know what I mean," but considering that I've kind of lost track of myself, I dunno what kind of luck you're having by this point.

Now, not to show my ignorance, but I'm not sure I caught the Simpsons reference. I've seen almost every episode, but even I couldn't decode it. Sigh.

Re:How to use it?

[tcopeland]

> I've kind of lost track of myself

Yup, I'm not sure where we're going with this one. On the other hand, this discussion is allowing me to procrastinate on applying a large and complicated patch to a project I'm working on, which is nice.

> I'm not sure I caught the Simpsons reference

Regrettably, I couldn't come up with one, but I left the reference in there just as an initial break-the-ice sort of thing. A sort of Slashdotters greeting, if you will.

Re:How to use it?

[PyromanFO]

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.

Re:How to use it?

[Anonymous Coward]

So, not an open standard.

Not a standard at all. Communication standards are created to allow communicating using a common protocol. These units, in effect, define the standard as they go.

Re:How to use it?

[standard method]

I was thinking it was kind of like a super-nerd Magic: the Gathering type game.

"I counter your SouthParkTiredReference with ObligatorySimpsonsQuote+1!"
"You sunk my battleship!"

Works for me, either way. Better stop now, though, before I start (keep?) going off-topic.

Re:How to use it?

[tcopeland]

> super-nerd Magic: the Gathering type game

All we need now are some Hitchhiker's Guide references and it'll be complete.

> going off-topic

Hopefully everyone else has already moved on to the killer asteroid article...

Re:How to use it?

[standard method]

Yeah, how about that asteroid, is it good or is it whack?

Oh man, I deserve to get modded down for that one. *hangs head in shame*

HitchHiker's Guide, huh? I'm reading an excerpt from the BBC's online h2g2, actually. Well, if we want to go uber-nerd (forgive the lack of umlaut), we'd need LotR, Star Wars, Star Trek, and a few others. We've already covered open source, code, and capitalism in this series of messages though, so I think we're good there.

Re:How to use it?

[tcopeland]

> how about that asteroid

Dude, there was this asteroid thing, and some dinosaurs, and, aw man, is that crazy or what?

> I'm reading an excerpt from the
> BBC's online h2g2,

Cool. I wish I could find that series on books on tape... 'twould make my commute much nicer. It'd be quite a number of tapes, though... the weight would probably cut my gas mileage in half...

Re:How to use it?

[gaudior]

Did you contact them? How do you know it is not an open standard?

This is a work in progress. API's may change. Protocols and all the fiddly bits underneath may not be set well enough for even a draft standard.

Licensing may be as simple as PARC requiring some information about your anticipated use of the protocols. Do not immediately jump to the conclusion that there is something fishy going on.

Now, it may be that there IS something fishy going on, but I haven't seen it yet. Remember, PARC has been the source of so much that we take for granted, for nearly 40 years. Much of that work has been put into the public domain, or openly licensed.

Re:How to use it?

[Draknor]

I would just like to say, I applaud this conversation. Doubleplus good! :-)

Re:How to use it?

[bentini]

Not if you write good code. Especially code that can write all the more code you need.

Re:How to use it?

[tcopeland]

> Licensing may be as simple as PARC requiring
> some information about your anticipated use
> of the protocols.

True, you're right, maybe giving them the benefit of the doubt would be better....

Re:How to use it?

[standard method]

My droogs and shoots, I viddy it's raz for an appy polly loggy, I'm a bolshy great bratchny for dunging up this mesto with my oozhassny chepooka and cal. Any of you gloopy, starry baboochkas horn about this though, and I'll fist you in the yarblockos. You all better be poogly in your neezhnies now, cuz if I viddy you all by your oddy knocky, your plott is mine for a bit of the old ultra-violence, and your em for the in-and-out, I'll give her a horrorshow lubblilubbing, my pan-handle up in her keeshkas.

-5, Offtopic. *sheepish* That doesn't make complete sense when translated, but, that's keeping with this "conversation", I suppose.

Sounds safe to me - pwned

[orthogonal]

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?

heh - The infinite IS possible with Obje

[Wingchild]

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:heh - The infinite IS possible with Obje

[bunnyman]

The infinite is attainable at zombo com!

Re:heh - The infinite IS possible with Obje

[benja]

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...

Wait, "mid-Atlantic?" Are you saying that Microsoft is tinkering with DNA in a lab in Atlantis, and you build it for them? Conspiracy!!!!!

Aaargh, where's my tinfoil hat? I had it somewhere here... noooooooo!

(Sorry.)

lpr -Pnewprinter

[Black Parrot]

Computer: Print this please.

Printer: BOOMshakalaka.

Computer: Print this please.

Printer: BoomshaKAlaka.

Computer: Print this please. ...

User: Damit, where's that old typewriter?

Re:lpr -Pnewprinter

[Linker3000]

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?

Could be horribly insecure

[moberry]

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

[SunCrushr]

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.

Re:Parc = Real PnP

[gbjbaanb]

yeah, is this the (universal) plug n play that almost every firewall blocks immediately?

Re:Parc = Real PnP

[drinkypoo]

So what you're saying is that it's essentially like OpenFirmware for networks? That's a case in which adapters installed into a system have their own code...

Re:Parc = Real PnP

[SunCrushr]

Yes, that is a good analogy. Of couse, it brings about all kinds of security questions. It will be interesting to see how such a thing is implemented, if it gains any industry acceptance at all, and if this company is as willing to open the technology/idea as they supposedly were with object oriented programming.

Re:Parc = Real PnP

[SunCrushr]

Yeah, UPnP has proven on more than one occasion to be insecure, its probably best that its blocked by most firewalls. Hopefully, with this protocol suite, and with it exchanging low level code to describe services and all that, they will find a way to secure it so people won't have to be afraid to use it. I guess its wait and see.

Re:Parc = Real PnP

[silas_moeckel]

I'ts been tried to an extent. USB and BlueTooth were supposed to work by providing a few standard interfaces making drivers standard. It seems to work somewhat. Windows has some very broken USB handaling try getting a serial dongle to work and you will find it asks for a disk often enough that disk most often contains the same dll as the system allready had for serial over USB, pretty much so it can say belkin usb to serial cable rather than generic usb to serial cable. IDE seems to be the only reliable usb driver.

Bluetooth has similar issues with things like headsets there are multiple possible drivers and one each end and no automated facility to match up the best capability profile that will work.

This would seem to be going to the way of i2o where you made a framework of half drivers the OS side that just had to get to i2o's middle ground and the card would provide the rest. With this you loosing some performance because you have arbitrary limits by the i2o framework.

I think the big stumbling block is going to be added cost it takes memory to store the driver. People want there devices cheap it would seem a better idea to fix bluetooth and usb as they are nearly there. Realy it's just a question of making devices pick the best match via a autonegotiation.

And in other news...

[papasui]

Apple Computers CEO Steve Jobs has been sighted spending large amounts of time in the Palo Alto area. When questioned Steve replied "Oh I've been doing some research for new products."

Re:And in other news...

[Anonymous Coward]

Note: Steve Jobs monster home is in downtown Palo Alto (a short drive from the PA airport helipad... and his aerial commute to Pixar).

Re:And in other news...

[papasui]

Ok so it's not funny.

Mobile Code?

[brain_not_ticking]

FTA:

"Standards Independant
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."
...
"Instead of working out all agreements in advance, The Obje platform specifies a few very general agreements in the form of domain-independent programmatic "meta-interfaces". These meta-interfaces use mobile code to allow new agreements to be put in place at run-time, enabling devices and services to dynamically extend the capabilities of their clients."

If this is "standards independant," what exactly is "modible code?" Wouldn't there have to be some sort of standard for that?

I guess it's not Obje, it's...

[Anonymous Coward]

Colussus II: Forbin Boogaloo

Ouiji, not Obje

[Lord Grey]

The Obje platform works with all standards, including those that have not yet been defined.

Based on that rather sweeping statement, they should have named it Ouiji instead.

"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)

Kids these days...

[Thud457]

When I was a lad, all we had was ISO-standard grunts. aWLITW!

Re:Kids these days...

[Anonymous Coward]

hmmmm.... methinks it's time to submit a RFC...

Re:Kids these days...

[Anonymous Coward]

Dammit. This thing deserves at least a +2 funny just for the phrase "ISO-standard grunts".

Sounds like...

[Anonymous Coward]

...Postscript.

History of the Future

[Danathar]

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? :)

Re:History of the Future

[Anonymous Coward]

No, this never happened before. Microsoft has always innovated. We have always been at war with EastAsia.

PnP + Windows Update + ...

[Wingchild]

From the Obje FAQ:

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.

Re:PnP + Windows Update + ...

[TexNex]

So basically this is the new version of Universal PnP. Except this version actually works.

Re:PnP + Windows Update + ...

[commander salamander]

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

Yeah, because we all love it when that happens.

I object!

[Guppie]

"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...

Re:I object!

[sjwt]

so who is goin to be the first to write a standerd that brakes Obje.

Sending actual code over a network?

[Anonymous Coward]

...sounds like downloading nightly builds from a CVS to me.

/has rtfa but everything else was already said

*ALARM BELLS*, but this IS PARC

[ItsIllak]

OK, I read the headline and could practically see the red lights circling into view and hear the alarm bells ringing. It's a really really obvious way of making life even more difficult!

However, I do have to remember that this is PARC we're talking about. They've got a pretty good track record of innovation. At very least I think they should be given a bit of rope. Hopefully they won't hang themselves with it!

Of course, I find it hard to see how this simplifies or improves computing and networking in any way, and it rips SO hard through the OSI models that it could be pretty damaging in that respect too.

OOG has prior art on this one...

[Thud457]

What the hell's wrong with OpenBoot?!!! Forth's a lot more lightweight than freakin' Java!!!!

Spammer's dream

[jtpalinmajere]

Enter the age where I can have my device tell your device to send a million copies of pr0n adverts to all my enemies. MWAHAHAHAHA!!!

Glad to see Jini getting some props

[JohnnyCannuk]

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!" :)

Finally, a use for Java.

[torpor]

Seems to me a mini-JVM would be good for this application, sitting in between the transport layer and the application.

Actually, come to think of it, why hasn't this been thought of before?! SO OBVIOUS!!

Ah well. I'm now happy that after all this time, I've finally come to understand that in fact there is a use for Java after all...

(j/k, don't slay me!)

Gee where have i seen this before

[Anonymous Coward]

ok let's see powered nanobots using a rat's heart, self teaching code. Damn it's skynet time !!! without the boobs.

Parent should be "Funny"

[Anonymous Coward]

Well, this (direct parent) is a message, that should be modded funny.

Platform independent embedded device driver?

[ahg]

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>

Re:Platform independent embedded device driver?

[cubic6]

The security concern I'm worried about is that this could be used to control devices that could cause harm to data or infrastructure, like a network card.

Say someone plugs into my network with a rogue device, which sends packets in some protocol my network card doesn't understand. My network card sees these strange packets on the wire, and asks rogue device to send code to interpret them. Rogue device sends back code that pingfloods the whole network and spoofs the source IP so it looks like our company fileserver is doing it.

Hopefully there will be controls in place to prevent this type of thing, but it's still another possible vector of attack. Judging by the track records for implementing security-related stuff, I just think we should be *very* careful in how this is implemented.

Active Networks - deja vu all over again

[decoy999]

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 ...

dont touch until it is mature

[Dr.Knackerator]

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.

One big difference

[Anonymous Coward]

" How is this different that Sun's JINI?"

JINI fails horribly under high loads.

I know... we had to rip it out of a large travel web-site because of random failure during high-loads.

I would touch JINI again if Barbara Eden was playing the lead role.

The network is the virus

[Anonymous Coward]

Cool. Now there's a whole new way of breaking the Net.

Extensive Driver Libraries

[Anonymous Coward]

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

[drinkypoo]

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.)

Re:Extensive Driver Libraries

[Directrix1]

Is this article referring to hardware interactions? I thought it was more along the lines of the introduction of remote sandboxed threads providing application specific custom service interfaces. This could very easily be done now with java (maybe its time for me to start a project). And if I ever get time, I might just start the project up.

Repackaging the magic of AppleTalk

[redtabby]

I can't wait until we have users attaching nifty
Obje devices all over the network, creating
ephemeral paths to cool stuff which come and go
with the pulsing of the helpdesk phones.

If anyone can get this right, it'll be PARC...

[alispguru]

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.

Re:If anyone can get this right, it'll be PARC...

[Anonymous Coward]

Didn't PARC also create the first computer worms?

Back then, someone thought that it might be useful to have worm computations that ran around, taking spare cycles from any machine available.

Get to know me!

[whyde]

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

[Gr8Apes]

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.

Now the important stuff

[UnknowingFool]

Forget about the implications to security and usability, what I want to know is how do you pronounce 'Obje'. I want to start mentioning it in conversations with PHBs to see how fast they can butcher the name and how fast before they start demanding it be installed on every computer.

PARCs strategy

[the_diesel]

1) Develop innovative computing paradigm 2) Allow it to be ripped off 3) Seem clueless 4) Develop innovative computing paradigm 5) Allow it to be ripped off 6) Exploit all systems 7) Profit Just because I'm paranoid doesn't mean they're not out to get me.

Re:PARCs strategy

[the_diesel]

1) Develop innovative computing paradigm
2) Allow it to be ripped off
3) Seem clueless
4) Develop innovative computing paradigm
5) Allow it to be ripped off
6) Exploit all systems
7) Profit

Just because I'm paranoid doesn't mean they're not out to get me.

(Please mod my parent post down)

Re:PARCs strategy

[triso]

You claimed PARC's strategy is:

1) Develop innovative computing paradigm
2) Allow it to be ripped off
3) Seem clueless
4) Develop innovative computing paradigm
5) Allow it to be ripped off
6) Exploit all systems
7) Profit

Can you give an example of PARC doing 6 and 7?

Beyond Contact

[Hythlodaeus]

This sounds a lot like the main idea in the book "Beyond Contact" - rather than try to send aliens little pictures coded in radio (like a lot of reverse-SETI ideas) send them a description of a VM followed by lots of little programs.

Solves a GPL problem

[Smallpond]

One thing this could solve would be keeping the details of the driver for a new device closed-source. That way a manufacturer could supply hardware and a built-in driver for use in Linux without having to open up the architecture to their competition.

This assumes that its not trivial to extract the details from the Obje code, of course.

huh?

[MagicM]

(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...

Omniscience

[Bugmaster]

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.

So, it's omniscient as well as omnipotent ? Singularity is here !

A Likely Virus Problem...

[punxking]

"I put my burrito in the [bluetooth enabled] microwave for one minute and now it won't stop!"

Another PARC Invention? Who Will Steal It?

[DoctorMabuse]

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

Does anyone remember The Forbin Project?

[tizzyD]

A lovely little film all about two very top secret computers--one in the US and one in the USSR. From a summary I found...

Dr. Charles Forbin has completed work on the greatest computer ever built: Colossus. The city-sized mainframe, built into an impenetrable Western U.S. mountain, independently controls the American nuclear arsenal. Coldly, rationally, it will assess threats to the U.S. and take action if necessary. The president tells the world such a computer, independent of human weakness, will create lasting peace. That lasts for only a few days when Colossus discovers his Soviet counterpart and begins communicating. Once merged, they tell U.S. and Soviet leaders that the foolishness of the Cold War must end. By threatening nuclear holocaust, the computers -- collectively called Colossus -- engineer assassinations and isolate governments. Dr. Forbin is put under house arrest. From his private rooms, he begins a mental battle with Colossus. He invents a sexual relationship with assistant Cleo Markham and Colossus unwitting provides Forbin with a confederate. Human efforts to short circuit the nukes are discovered by Colossus who punishes the earthlings with nuclear detonations. As Colossus makes a global broadcast announcing its intention to enforce peace through strength ("Freedom is an illusion," it says), the film ends.

Interestingly, the computers learn to talk to each other through mathematic equations.

Can anyone find downloadable code?

[gabbarsingh]

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

[gabbarsingh]

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.

You are so right

[lokedhs]

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.

Re:You are so right

[JohnnyCannuk]

I am afraid you are under the wrong impression of what Jini is or does.

Jini is a distributed services platform. It distributes those services in a certain way, based on a Service Oriented Architecture and mobile code. That's it. Jini provides some core services, but the creation of services is up to the developer.

Take Javaspaces, for instance. Not only is it a spec, it is also an example of a Jini Service.

If you want a distributed file storage, go to www.jini.org and find one. Not there? Start one. Jini is not a protocol, it is protocol independant. Use any protocol you want in your service.

Ironic that here on /. that someone would be complaining that they have to take part in a community process to get what they want!

You may want to check it out now.

BTW, read the spec and implement Jini yourself if you think thestarter kit is "crappy". You even get the source code to refactor, if you like.

Re:You are so right

[lokedhs]

Well, first of all you obviously wasn't part of the early presentations by Bill Joy. You're describing the situation 5 years later.

The presentations went something like this: "look! now we can have our devices discover all the services they need! the digital camera can find the file storage to save the pictures on!". A pity they had no interest in actually defining or even suggesting how the file storage should be accessed. The people over at jini.org were "working on it" but nothing had happened over a year later.

If I had designed a file storage, do you seriously think the digial camera manufacturers would comply with it?

If it works better now, fine. I'm happy for you. Personally I lost all interest in Jini, and Obje seems to be exactly the same thing. You very elegantly avoided the core issue, explaining why Obje would succeed where Jini failed.

reinventing the wheel

[ajagci]

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.

the same ideas, over and over and over again

[ajagci]

Do you seriously believe that Sun invented mobile code with Jini or Java? In reality, none of that stuff is new. Just about every idea in Jini was taken from other systems, and the combination also doesn't really offer much that is new. In any case, PARC's Obje addresses a different problem. But the problem it addresses has also been addressed before. If at least the new implementations were simpler and more open than their predecessors, but, being Java based, both Jini and Obje are actually worse.

Re:the same ideas, over and over and over again

[Anonymous Coward]

Why was this modded 2? This post seems to be high-rant, low-information - to wit:

" Just about every idea in Jini was taken from other systems, and the combination also doesn't really offer much that is new. "

Examples??

"In any case, PARC's Obje addresses a different problem. But the problem it addresses has also been addressed before."

I almost follow you here...

"...being Java based, both Jini and Obje are actually worse."

Because...??

Facts. Not just a good idea.

Re:the same ideas, over and over and over again

[JohnnyCannuk]

Ohh, touchy.

Well, I never claimed that Sun "invented" mobile code with Jini, just that the ideas espoused by Obje have been done before and are currently available for anyone to download from www.jini.org .

So, seriously, what other past implementations of this have there been? I am really curious.

As for your cracks about the real problem being a Java-based implementation, I will take it you are one of those "if it ain't GPL it ain't free" zealots. So please, provide links to the C++ version of a Jini-like framework. Or the Ruby version. Or the Python. Or C. Anything as long as it is OSS certified. While your at it, point me to the one that has the default sand-box for running the mobile code, making it more secure - other than a Java implementation.

My idea of giving "props" was because the referenced article mentions that "Obje can be built on top of mobile-code frameworks like Jini"...and Jini has historically been "ignored" even within Sun.

Or did you not bother with the formality of actually reading the article?

Hmmm?

And if Jini and Obje address different problems, perhaps you can enlighten me just what problems they each address that is so different, 'cuz it looks pretty identical to this Jini programer.

Re:the same ideas, over and over and over again

[ajagci]

Well, I never claimed that Sun "invented" mobile code with Jini,

Sure you did; that's what the term "using the idea [...] from Jini" means, and you yourself indicate later that you don't seem to know of any previous systems:

Glad to see PARC is using the idea of mobile code from Jini.

So, seriously, what other past implementations of this have there been? I am really curious.

Lots of Lisp and Scheme systems, plus many other systems based on scripting languages like Tcl. Many database systems have used mobile code extensively, including sandboxing (clients would send Pascal or Basic code to the database server to speed up queries). It used to be part of distributed programming, then it became software agents. Several of them, of course, offered sandboxing, because one obviously needs that for that kind of system.

As for your cracks about the real problem being a Java-based implementation, I will take it you are one of those "if it ain't GPL it ain't free" zealots.

As before, you are wrong and jumping to conclusions. No, in this case, I'm not referring to the fact that Java is proprietary software, I'm pointing out that it sucks technically at these kinds of applications: it has a bloated runtime, a poorly conceived system for sandboxing, and an unnecessarily complex reflection system.

And if Jini and Obje address different problems, perhaps you can enlighten me just what problems they each address that is so different, 'cuz it looks pretty identical to this Jini programer.

Jini fails to address the problem of ontological mappings between service descriptions, Obje tries to (but ignores at least a decade of prior work).

Re:the same ideas, over and over and over again

[Anonymous Coward]

" Just about every idea in Jini was taken from other systems, and the combination also doesn't really offer much that is new. "

Examples??

Linda; mobile code and software agents.

"In any case, PARC's Obje addresses a different problem. But the problem it addresses has also been addressed before."

I almost follow you here...

See work on web services description frameworks, semantic web, and ontologies.

"...being Java based, both Jini and Obje are actually worse."

Because...??

Because they both end up having a huge runtime and sandboxing and reflection mechanisms of enormous and unnecessary complexity.

Why was this modded 2? This post seems to be high-rant, low-information

Of course, it was "high-rant, low-information". May one not rant a little on Slashdot? And given the "high-rant, low-information" junk that Sun marketing spews out, to the tune of probably hundreds of millions of marketing dollars every year, why is every criticism of their system supposed to be a high-brow technical treatise?

Excuse me

[autopr0n]

Did you just say that Cisco has a project called "Spanish Inquisition"?

Who would've expected that?

Re:Excuse me

[MoronGames]

Did you just say that Cisco has a project called "Spanish Inquisition"?

Who would've expected that?

Nobody expects the Cisco... err... Spanish Inquisition!

That is a bizzare statement

[autopr0n]

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.

Yup

[autopr0n]

Wait...did'nt this happen before? :)

Just four or five times in this thread already.

August 20, nnnn

[Anonymous Coward]

And using breakthru PARC technology, OBJE redeclared itself SKYNET, August 20, nnnn.... ...gonna need a bigger tinfoil hat!

SETI might find this useful

[Anonymous Coward]

"Essentially, it allows two devices to teach each other how to talk amongst themselves. It does this by sending actual code over the network."

Hmmm. The lessons learned here might be useful in other unforeseen applications.

Imagine, if you will, that SETI actually does discover another intelligent life form. I can just see the techniques used here being applied to trying to learn how to communicate with the other side.

Worst case, one of our devices would be talking to one of their devices, and the computers decide that no one else really matters. :)

Ahh, the possibilities for some interesting science fiction seem numerous.

Active Networks?

[kyoko21]

From reading just what was posted regarding sending code over networks to learn, it sounds like something related to my friend's thesis on Active Networks.

Sandboxing doesn't solve the problem

[hypnagogue]

Sandboxing is not a cure all -- it specifically does not prevent DOS attacks from sandboxed code that "runs hot", either with respect to hardware or network resources.

If another device in the internet can send you code that you execute, sandbox VM or not, it can DOS you. This idea seems flawed from the outset.

And now we finally know...

[voixderaison]

...how it was that a human laptop could talk to the alien mother ship in ID4. Independence Day continuity

Re:And now we finally know...

[Anonymous Coward]

Well, it would have worked if the laptop was a MAC Powerbook. After all, aren't all the aliens on earth work for Apple?

Windows only?

[mattyrobinson69]

will this code be win32 code only? bit of a pain in the arse for unix users