[
https://issues.apache.org/jira/browse/ZOOKEEPER-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Koch reassigned ZOOKEEPER-911:
-------------------------------------
Assignee: Thomas Koch
> move operations from methods to individual classes
> --------------------------------------------------
>
> Key: ZOOKEEPER-911
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-911
> Project: ZooKeeper
> Issue Type: New Feature
> Components: java client
> Reporter: Thomas Koch
> Assignee: Thomas Koch
>
> Copied from my email to the ZK dev list from 2010/05/26:
> For my current code I'm using zkclient[1] and have also looked at cages[2]
> for
> some ZK usage examples. I observed, that there's a common pattern to wrap ZK
> operations in callables and feed them to a "retryUntilConnected" executor.
> Now my idea is, that ZK should already come with operations in classes, e.g.:
> o.a.z.operation.Create extends Operation implements callable{
>
> private path, data[], acl, createMode
> public Create( .. all kind of ctors .. )
> public call(){
> .. move code from Zookeeper.create() here
> }
> }
> Similiar classes should be provided for getChildren, delete, exists, getData,
> getACL, setACL and setData.
> One could then feed such operations to an ZkExecutor, which has the necessary
> knowledge about the ZkConnection and can execute a command either
> synchronously or asynchronously.
> One could also wrap operations in an ExceptionCatcher to ignore certain
> Exceptions or in a RetryPolicy.
> This is only an idea so far, but I wanted to share my thoughts before
> starting
> to try it out. (BTW: You can meet me at BerlinBuzzwords.de)
> [1] http://github.com/sgroschupf/zkclient
> [2] http://code.google.com/p/cages/
> And a reply from Patrick Hunt at my mail:
> Hi Thomas, you might take a look at this JIRA
> https://issues.apache.org/jira/browse/ZOOKEEPER-679
> there's definitely been interest in this area, however there are some
> real challenges as well. Most users do end up wrapping the basic api
> with some code, esp the "retry" metaphor is a common case, so I think it
> would be valuable. At the same time getting the semantics right is hard
> (and covering all the corner cases). Perhaps you could sync up with
> Aaron/Chris, I'd personally like to see this go into contrib, but I
> understand the extra burden the patch process presents -- it may make
> more sense to rapidly iterate on something like github and then move to
> contrib once you have something less frequently changing, where the
> patch issue would be less of a problem (see 679, there's discussion on
> this there). Regardless which way you take it we'd be happy to work with
> you.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
