Seems like a good thing to have, for sure. I'd say following the model
of extending the API is a better choice, and leave the Zookeeper service
as light as possible. This has been done for languages like Perl and
Python, and it seems natural to me to extend for WSDL/REST as well. I
realize this isn't quite the same in that you'd be running a service
rather than creating another programming API, but it seems to fall under
more of a 'contrib' scenario than something that should be native to the
Zookeeper service itself. That's my humble two cents. :-)
Chris Medaglia
ITA Software
On 3/29/11 Mar 29, 2011 3:56:32 PM, Oliver Wulff wrote:
Hi there
I can get access to the data stored in the zookeeper servers with the
zookeeper client only. I'd like to provide a WSDL or REST interface to
clients to read and maybe write information. I see two options
1) The WSDL/REST facade is deployed within the zookeeper server and runs
within the same operating system process
2) The WSDL/REST facade is installed on the same machine but within a
seperate process and uses the zookeeper client api
IMHO, I'd prefer the 1st option but don't know whether this is possible. I
also had the idea to deploy the zookeeper server into an OSGi container and
the facade is a seperate bundle.
Which solution makes more sense to you and why?
Thanks a lot
Oliver
