Perl JINI

[David Dick]

ok, i've had a lot of fun thinking about this one. :)

Conclusions:

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 
readable form)
could have a separate protocol for calling methods.
may need auth, caching as add ons..

So.

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.

Uru
-Dave

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