On Wed, Jun 25, 2008 at 06:27:00PM +0200, Stefan de Konink wrote: > Daniel P. Berrange schreef: > >If I'm understanding what you're doing, it is sort of a REST style > >web services API. > > Why is everyone using this REST buzzword lately? :D Useful to distinguish from other web services APIs like SOAP or WSDL. REST is nice & crack-free :-) > It is what I proposed to be in libvirtd (native support for clouds), but > then implemented as a client application for libvirtd, that is a service > provider for avahi. And a webserver plugin for Cherokee that is a client > for avahi. Something as namespace collision prevention is something that > is 'on going'. How tied is the webserver plugin to Cherokee - I think you'd get more interest if there was the option to plugin to apache, since Cherokee isn't very widely used / known by comparison. Having never written plugins for either I don't know if this is possible, but having a generic plugin for the application logic and then bridges to apache, cherokee & other web servers would be nice. > >I'd be interested in seeing the source to understand better what it > >is doing. I'd certainly be fine with adding it to our applications > >page on the website & wiki. > > http://repo.or.cz/w/handlervirt.git I've had a quick look, but not got it up & running due to not having cherokee in Fedora. My first thought would be that the URL spec needs to be more fine-grained / well-defined. Virtual machine names are only guarenteed to be unique to a single host, so with your avahi broadcasts aggregating info from multiple hosts you will inevitably get namespace clashes based on name alone. I'd provide several parallel URL spaces based on the different naming /vm/{UUID}/ /host/{HOSTNAME}/vm/{NAME} /host/{HOSTNAME}/vm/{ID} UUID is guarenteed to be unique globally, while the other two are only per-host unique. I included the /vm/ prefix under the /host/ so you can also expose other bits of per-host information such as networking, capabilities and device info, eg for virtual networks: /vnet/{UUID}/ /host/{HOSTNAME}/vnet/{NAME} I'd also thing of structuring it so that the default install just gives info on a single host, and then have an add-on plugin to enable the multi-host aggregration. You could have a /local/ shortcut URI to refer to the /host/{HOSTNAME} of the local machine. This gives admins the flexibility to run a mini web service on each node, or have a central service on a 3rd part node. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list