I'm excited to see OpenWFERu happening. So a hello to everyone else spending some time on this. It's always nice when a package is available in a language you yourself are having a good time using, and I think ruby is well suited as a language for workflow. I'm hopeful ruby is also the place for a good community around OpenWFEru (rufus), the ruby world is pretty welcoming and friendly, and isn't flooded with workflow solutions already.
At some point (perhaps a few more revisions etc) it might be nice to reach out to the flow / torrentflow / workflow4r etc folks, and see what useful pointers etc they might have, as we are all probably trying to solve similar sets of problems.
John Mettraux posed some interesting questions, and I thought I'd run with them here.
These are some the itches I'd be somewhat interested in scratching in the OpenWFERu context.
A workflow system / engine that:
- Takes advantage of the ruby / ruby on rails world...
- I lean towards a higher performance solution that can handle lots of small webapp type tasks (ie, down to things as small as new user registration and the states and steps in that) efficiently. EVERY website has lots of these little workflows, where state needs to be tracked over a series of items. Or it could be clear where something like SMC fits, some things do make more sense hard coded.
- Emphasize a simple start. I think it's worth focusing on the simple and often used cases to get people more familiar with the technology. Then all the many many ways to set up workflows make sense, and it lowers the barrier for community growth.
- Work to build a good developer community. This means focusing resources on getting new developers up to speed, and good developer style documentation. Lots of user help of course, but see if users can help users and learn. Folks who understand the internals can help get others understand the internals. I'd love just a brief doc in the source directory with a bit more of a high level overview of how the code ties together. The comments look good already!
- Has a workflow designer that mere mortals can use to get at least started in, even if they edit the resulting workflow definitions, they have a template for what they want to do. Hard though, I don't want to work on that :)
Some specifics, and I throw these out there knowing they may get shot down, I don't mind, these are meant to be ideas only.
- Look at using YAML as a markup for process definitions. YAML is one of the default ruby configuration languages with some nice features. Syck [http://whytheluckystiff.net/syck/] is going to be in Ruby 1.8 core, and provides a very fast interface to YAML with Kwalify or similar for validation etc. Perhaps start with things as simple as the datasource definitions, though I didn't see them in Rufus.
I've dug through the code very briefly (are all the needed bits in the svn repo or documentated? tidy / redcloth etc etc), and will be able to look at it again after Christmass.
I'm hopeful I can be helpful with some basic cleanups / tracking etc. And at some point perhaps some actual contributions.
Happy holidays, and thanks thanks thanks for making this available!
On 12/25/06, August Zajonc <augu...@augustz.com> wrote:
> I'm excited to see OpenWFERu happening. So a hello to everyone else > spending some time on this. It's always nice when a package is > available in a language you yourself are having a good time using, and > I think ruby is well suited as a language for workflow. I'm hopeful > ruby is also the place for a good community around OpenWFEru (rufus), > the ruby world is pretty welcoming and friendly, and isn't flooded with > workflow solutions already.
Thanks for your interest, the Ruby world seems indeed very friendly.
> At some point (perhaps a few more revisions etc) it might be nice to > reach out to the flow / torrentflow / workflow4r etc folks, and see > what useful pointers etc they might have, as we are all probably trying > to solve similar sets of problems.
Maybe, though it's difficult for open source projects addressing similar problem domains to collaborate, but sure, sometimes it happens.
> These are some the itches I'd be somewhat interested in scratching in > the OpenWFERu context.
> A workflow system / engine that:
> - Takes advantage of the ruby / ruby on rails world...
100% with you.
> - I lean towards a higher performance solution that can handle lots of > small webapp type tasks (ie, down to things as small as new user > registration and the states and steps in that) efficiently. EVERY > website has lots of these little workflows, where state needs to be > tracked over a series of items. Or it could be clear where something > like SMC fits, some things do make more sense hard coded.
Very interesting, you could become our CPO (chief performance officer) then ;-) making sure the engine is performant.
> - Emphasize a simple start. I think it's worth focusing on the simple > and often used cases to get people more familiar with the technology. > Then all the many many ways to set up workflows make sense, and it > lowers the barrier for community growth.
A quickstart document would be a plus then. Little website workflows is a domain I have never personally explored, I always focused on (warning big bad word) BPM and producing a "Business Process Engine". But there is no incompatibility with a "little embeddable workflow engine".
> - Work to build a good developer community. This means focusing > resources on getting new developers up to speed, and good developer > style documentation.
Having worked on OpenWFE since 2001, I have to say that having a good developer community is something hard, but the means you mention do make sense. I never emphasized on devel documentation, maybe with Rufus, I could switch tactic.
> Lots of user help of course, but see if users can > help users and learn. Folks who understand the internals can help get > others understand the internals. I'd love just a brief doc in the > source directory with a bit more of a high level overview of how the > code ties together. > The comments look good already!
Thanks.
> - Has a workflow designer that mere mortals can use to get at least > started in, even if they edit the resulting workflow definitions, they > have a template for what they want to do. Hard though, I don't want to > work on that :)
There are already process designers for OpenWFE, hence for OpenWFEru (same language).
Of course a new, nicer, better editor written in Ruby would be a plus (and it could be used for OpenWFEja as well).
> Some specifics, and I throw these out there knowing they may get shot > down, I don't mind, these are meant to be ideas only.
Thanks for daring.
> - Look at using YAML as a markup for process definitions. YAML is one > of the default ruby configuration languages with some nice features. > Syck [http://whytheluckystiff.net/syck/] is going to be in Ruby 1.8 > core, and provides a very fast interface to YAML with Kwalify or > similar for validation etc. Perhaps start with things as simple as the > datasource definitions, though I didn't see them in Rufus.
What's a datasource definition for you ?
Your YAML idea for process definition is interesting, I'll dedicate a sub-thread to it.
As Rufus isn't yet persisted, we were exploring JSON and YAML as format for persisting the expressions (a [running] workflow instance] being a set of expressions). Out of the box, OpenWFEja (java) is using XML to store the expressions (and the workitems) in a filesystem hierarchy.
We feel like we could use JSON or YAML to store efficiently data to the disk (db persistence is not a priority). But XML is more internationalization-friendly (UTF-8 is a must).
> I've dug through the code very briefly (are all the needed bits in the > svn repo or documentated? tidy / redcloth etc etc), and will be able to > look at it again after Christmass.
Yes, everything is in the SVN tree, we hope we'll be able to stick to that practice (no external wiki/other for now).
> I'm hopeful I can be helpful with some basic cleanups / tracking etc. > And at some point perhaps some actual contributions.
Yes, let's start slowly, discuss, work and contributions will come naturally.
On 12/25/06, August Zajonc <augu...@augustz.com> wrote:
> - Look at using YAML as a markup for process definitions. YAML is one > of the default ruby configuration languages with some nice features.
I don't know much about YAML (yet).
So the idea is to expression process definitions in YAML instead of XML.
Currently the references about XML in OpenWFEru do appear in two files :
lib/ru/expressionpool.rb lib/ru/fe_raw.rb
If we would allow for YAML definitions, we'd have to provide a RawExpression implementation for it and to make sure lib/ru/expressionpool.rb isn't XML focused.
I'm wondering, maybe you already know, how would we represent this classical OpenWFE process definition in XML
> On 12/25/06, August Zajonc <augu...@augustz.com> wrote:
>> - Look at using YAML as a markup for process definitions. YAML is one >> of the default ruby configuration languages with some nice features.
> I don't know much about YAML (yet).
I'm afraid I've not looked at it much either but it seems useful to use in Ruby since it is tightly integrated in with Ruby.
> So the idea is to expression process definitions in YAML instead of XML.
Yes that would be a worthwhile goal. One question that will need to be explored is whether YAML can fully handle all of the process definitions for XML. If not, how far can it go? Probably the best way is to write simple programs and test it out as we go. I'm afraid my understanding of the internals of the workflow engine are too weak to be able to determine this from pure analysis alone right now.
> Currently the references about XML in OpenWFEru do appear in two files :
Excellent, I'll have a look at these tomorrow morning.
> If we would allow for YAML definitions, we'd have to provide a > RawExpression implementation for it and to make sure > lib/ru/expressionpool.rb isn't XML focused.
I think one other thing to keep a focus on is probably having some code snippets or even a tool that allows XML -> YAML -> XML where both XML expressions should be exactly the same or functionally equivalent. Having a tool and putting it in a unit test might be very helpful in order to determine if the YAML definition will start straying from the XML one because of 'various technical reasons'.
> I'm wondering, maybe you already know, how would we represent this > classical OpenWFE process definition in XML
> the ruby world is pretty welcoming and friendly, and isn't flooded with > workflow solutions already.
I wasn't aware of other workflow engines in Ruby. Perhaps it would good to collect a list of all known ones in order to build a comparison chart.
> A workflow system / engine that:
> - Takes advantage of the ruby / ruby on rails world...
Yes, I think that's a very good idea. A bit more documentation on how to embed Rufus into a Rails project would be really beneficial for a developer. I'm trying to get up to speed on rails now and see how this might mesh together.
> - Emphasize a simple start. I think it's worth focusing on the simple > and often used cases to get people more familiar with the technology.
Yes, I agree. My main focus besides keeping the build scripts in Rufus humming properly is writing documentation from a developer perspective trying to use Rufus. Right now, I think the documentation is extremely bare and trying to use Vamsee's Guide as a newbie tutorial has already brought up pieces of Rufus that will need to be written or altering the tutorial itself.
> - Work to build a good developer community. This means focusing > resources on getting new developers up to speed, and good developer > style documentation. Lots of user help of course, but see if users can
This is my first focus. Rufus is great but without documentation focused towards an outside developer it's like inheriting a 747 without the pilot's manual :-)
> - Has a workflow designer that mere mortals can use to get at least > started in, even if they edit the resulting workflow definitions, they > have a template for what they want to do. Hard though, I don't want to > work on that :)
I think this is also important. And probably something that could be done in Rails / Web2.0/ buzzword compliant however this is on the backburner to focus #1.
> - Look at using YAML as a markup for process definitions.
Please see my other reply on this.
> I've dug through the code very briefly (are all the needed bits in the > svn repo or documentated? tidy / redcloth etc etc), and will be able to > look at it again after Christmass.
Mostly. I have to add proper dependencies and better documentation on what tools you should install so you can get it all over in one shot without being unpleasantly surprised you need library Foo to do Bar.
> I'm hopeful I can be helpful with some basic cleanups / tracking etc. > And at some point perhaps some actual contributions.
Sure, always looking forward to it. I don't do much besides ask dumb questions to John anyways :)
|
