david_dick at iprimus.com.au
Fri Oct 10 17:13:21 CDT 2003
ok, i've had a lot of fun thinking about this one. :)
Advertising methods for machine -> machine communication is imho hard
enuff that it defeats the goal of small and easy.
Advertising methods for machine -> human is much easier and probably
what you have in mind?
My part of the elephant involves a gui that presents a list of
method/parameter values as a human readable description. eg:
Main Light [ On | Off ] -> http://home/lights.cgi?Light=Main&Value=x
Maximum Apache Processes [ 50 | 20 | 10 | Off ] -> https://dsfddfs
Current CD to Play [ xxxx | yyyy | zzzz ] -> jabber://sdssfsdf
Therefore, to my way of thinking, the protocol would be
hopefully text based :),
would need methods to come as a pair (the command string and the human
could have a separate protocol for calling methods.
may need auth, caching as add ons..
1) Gui fires up. Listens for broadcasts from servers (probable zeroconf
would be fine here)
2) Gets a response that indicates a server knows how to advertise methods.
3) Requests and receives a list of (command/parameters, description)
(that may come with a cache time before you need to request again)
4) Presents that list to a user.
5) When the user selects a method/parameter command, the gui issues the
related command to the service.
> 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 server
> * Automatic detection of capabilities or services
> - This is hard to define. In JINI it is simply a Class and
> - 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)
More information about the Melbourne-pm