Scott Penrose scottp at
Thu Oct 9 20:18:46 CDT 2003

Hash: SHA1

On Friday, Oct 10, 2003, at 10:52 Australia/Melbourne, Joshua Goodall  

> Three alternatives spring to mind
> i) Spread  (
>    (for which I have FreeBSD and Debian packages:

I had forgotten spread - thanks. This is particular good for high speed  
and very remote apps. Unfortunately it is not really good on the  
automatic discovery. Like many other alternatives (even Jabber) - it is  
only the transport layer and has not defined the way of detecting  

One of the key features of JINI is the detection of a devices purpose,  
features, methods and events.

> ii) Tib/Rendezvous ($$$ !)
> ( 
> default.jsp

Rendezvous is zeroconfig (or an implementation of it). Howl is one of  
the open source alternatives to Rendezvous - 100% compatible.
So good news for me who doesn't want to spend $$$ ! :-)

> iii) PerlDSM (distributed shared memory), if you can find it.

Again, interesting but not solving any of the actual requirements,  
which I probably have not made very clear. Remote procedure calls or  
sharing memory is not really a viable way of adding an adhoc network of  
devices together.

Unfortunately the main reason to rule out spread and PerlDSM is  
performance and functionality. They are too large and power / processor  
/ memory hungry for small embedded devices. I don't want anything more  
complicated than an HTTP 1.0 protocol.

There are literally 100s of applications and protocols in the space of  
communicating across a network. None of them unfortunately actually  
solve any of the problems that JINI is solving. The standard  
advertising and interaction of services in an adhoc network without  
single points of dependence or failure (some of the failure parts have  
to be handled by other things, such as networking gear etc).

Like HTML where you can invent a new tag - JINI allows you to invent a  
new device and stick it into the mix. Like SNMP which provides a  
standard set of functions you don't need to define (hello are you  
there, who are you) - JINI has standard ways of knowing the type of  
device and its methods / capabilities.

So what I am not trying to solve:

	* Remote procedure calls
	* Caching
	* Shared memory
	* Inter Process Communications
What I am trying to solve:

	* Automatic detection of devices
		- seems zeroconf is the go here
		- This is only the network layer though, no application
		- Effectively you now have an IP number and named
		  devices from which to communicate.
		- zeroconf then tends to use standard ports (80 for web) to
		  find the device services, - eg: Print Daemon, Chat client, Web  

	* Automatic detection of capabilities or services
		- This is hard to define. In JINI it is simply a Class and Methods
		- The class of type X is a Light and you just use the on method
		- This is sort of like solving the RPC Portmap problem
		- The only real solution is to start up an open registry
		  of device names and types.
		- Automatic registration (like CORBA) of Class and Methods is
		  cool, but your application still has to support it.

	* Very small
		- I want to be able to write (like you can with HTTP), 50 lines
		  of code and get a basic working version.
		- This means you can write a tiny tiny device on a PIC that
	  	  will still work.
		- The nice bit of using zeroconf here might be that the
		  zeroconf part is actually optional.
		  eg: a little PIC could have a hard coded address

	* Totally platform and product independent.

	* Implementation independent. (eg: not depending
		on perl, or spread, or howl etc)

- -- 
Scott Penrose
Open source developer
scottp at

Dismaimer: Open sauce usually ends up never coming out (of the bottle).

Please do not send me Word or PowerPoint attachments.
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see


More information about the Melbourne-pm mailing list