On 15/08/2013, at 5:51 AM, Anand Babu Periasamy wrote: > Here are some more points to consider: > > * gluster-devel package should include all the necessary header and > library files to compile a standalone glusterfs translator. That definitely makes sense. :) > * /usr/share/doc/gluster-devel/examples/translators/hello-world "template" might be a better name than "hello-world", just because it's purpose is then even clearer. > should contain skeleton translator code (well commented), README.txt > and build files. This code becomes the starting point to implement a > new translator. Make few changes and you should be able to build, > install, test and package your translator. Yep, this makes good sense too. > It is ideal to implement this via script. Similar to autoproject, > "translator-gen NAME" should produce all the necessary skeleton > translator code and associated files. This avoids erroneous > find-replace steps. An approach to automate away the error prone, repetitive setup stuff makes sense. Not strictly needed for an initial version of the feature, but it makes sense if time allows, or in a follow up version. :) > * "Getting Started" documentation, API documentation (including > libglusterfs APIs) Yep, definitely required. > * Modular GlusterFS CLI API. Today it is hard-coded. Not so sure about this one. Allowing for dynamic additions to the CLI (eg using the meta-data in the JSON fragment) sounds like a feature of it's own. Could be a bunch of work in itself, and it's not really a core requirement. Like the automated scripting bit, it's probably a "nice to have" if time allows. :) > * Modular volume spec file: each translator should distribute its > own volume spec snippet and a rule to load (say client only or server > only, possible injection points). Makes sense. We might find it easier to have different subdirs for different translator types (eg nfs/ client/ server/ ?). That could be over-complicating things though. ;) > * Modular documentation API: each translator should describe what it > does, what options its supports, default values and meaningful range > of values. Interesting. :) The JSON file already has all of that info specified in it, except for a "description" field, which should be added. > This doc should be query'ble via gluster CLI Definitely sounds like part of a "modular CLI" subproject, not part of this one right away. ;) > I really hope this initiative gets prioritized for 3.5. We need to > make it easy for community to contribute translators easily. Completely agree. If we get this right, it's a huge enabler to people customising Gluster how they want + being able to share things easily. :) Are you ok with the above item adjustments? If so, I'll incorporate them info the Feature page for this. + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift
