Hi Oli, > Some newer workflows partially use "I18N_OPENXPKI_WF_TYPE*" (Id of the > Workflow) and "I18N_OPENXPKI_WF_ACTIVITY*" (Name of the Action) already > > I would suggest to use "I18N_OPENXPKI_WF_VAL*" and > "I18N_OPENXPKI_WF_COND*" as common prefix for Validators and Conditions. > For better reading I would also suggest "I18N_OPENXPKI_WF_ACL_*" as > shortcut for ACL Conditions and to rename the Action prefix to > I18N_OPENXPKI_WF_ACTION*", so the prefix matches the name of the XML Tag. > > For the individual names one should use or at least derive the name from > the actual package name which provides the default implementation. To > give some freedom to 3rd parties, we might relax this to just use a > unique prefix. > > The "state" names exist only inside one workflow and therefore do not > need any unification. For the descriptions of the states and workflows, > the concept already used in > workflow_def_certificate_revocation_request.xml looks fine for me: > > workflow-type is I18N_OPENXPKI_WF_TYPE_<workflow name> > state description is I18N_OPENXPKI_WF_STATE_<workflow name>_<state name> > > Workflow name is equal to the name of the xml file. If the state > description should be reused within similar workflows, it would be wise > to split the workflow name in a group part and an individual part and > use the fomer one for the description tags.
your naming conventions sound sensible. In the past it was more or less "free style", sometimes adhering to the I18N_ syntax, sometimes with "speaking" names. Unfortunately Workflow does not support name spaces for activities, conditions and validators (but it does for states), so we do need to address this properly in order to avoid unexpected behavior when clashes happen. Soon we will be redesigning all the workflows in order to introduce the planned clustering support, so I think adhering to the suggested naming convention might be a good idea. In the same context I also would recommend to set up a shared or common namespace where all our commonly used activities, conditions and validators should go. All activities, conditions, validators that are explicitly written with a special purpose in mind should be subject to the naming conventions above, but those which can server a general purpose should go to a common directory and named accordingly. When redesigning the workflows we should also aim at offloading as much as possible to general, atomic parts that can be reused. An example is the WFObject class hierarchy and the corresponding WF items. cu Martin ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
