Patrick Hunt commented on ZOOKEEPER-78:

This first set of comments is relative to the structure/build/packaging (ie 
non-code) issues:

I think the jar name should include "recipes"
ie for locks: zookeeper-3.2.0-recipes-lock.jar
how about a "superset" recipes/zookeeper-3.2.0-recipes.jar with all recipes 
  users can choose which to use

There seems to be an issue with recipes in release build - actually same issue 
with contrib:
you cannot run "ant test" on lock recipe in the released tar file build using 
"ant tar"
  seems build.xml and build-recipes.xml are missing from tar file

docs - I think it's ok not to have specific forrest docs inside locsk, but need:
  what is this code? what are requirements for authors? (like interop btw 
c/java for particular impl)
  also req that recipe be documented in recipes documentation in forrest
  describe and point to forrest docs in docs/... (should put link to live h.a.o 
doc as well)
  is there some high level bit of informatin that you want to convey to authors 
re how components
    should be designed (in particular session mgmt, error handling, logging, 
etc...) this is a good place to put
  describe and point to forrest docs in docs/... (should put link to live h.a.o 
doc as well)
  pointer to javadoc (ie live h.a.o site)?

are the forrest recipe docs up to date relative to impl for locks? which lock 
in particular from docs.
  any deviation(s), any specific impl detail that's important, configurability?
  might be good to update the forrest recipe docs to point to this jar/code for 
  ie let users know that they can get this from the release in recipes/locks 
(they don't need to impl)

how do we verify interop?
  great job adding tests! but they seem to be tests for c, tests for java, but 
not interop.
  this seems pretty important. We want to document in recipes/readme that 
authors in particular
  should code for c/java to interop for any one particular recipe instance. 
also that recipes can 
    co-exists in user space (ie placement of nodes, etc...)
  Might be good enough to add a new JIRA for this, but need to impl this asap.

You've done a great job, but I'm holding this jira to a higher standard since 
ppl who implement further
recipes will use your lock implementation as a "blueprint". :-)

> added a high level protocol/feature - for easy Leader Election or exclusive 
> Write Lock creation
> -----------------------------------------------------------------------------------------------
>                 Key: ZOOKEEPER-78
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78
>             Project: Zookeeper
>          Issue Type: New Feature
>          Components: java client
>    Affects Versions: 3.0.0
>            Reporter: james strachan
>            Assignee: Mahadev konar
>             Fix For: 3.2.0
>         Attachments: patch_with_including_Benjamin's_fix.patch, 
> using_zookeeper_facade.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch, 
> ZOOKEEPER-78.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch, ZOOKEEPER-78.patch
> Here's a patch which adds a little WriteLock helper class for performing 
> leader elections or creating exclusive locks in some directory znode. Note 
> its an early cut; am sure we can improve it over time. The aim is to avoid 
> folks having to use the low level ZK stuff but provide a simpler high level 
> abstraction.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to