Re: OSW: doAction, codebase, features and Roadmap

I agree with a lot of your points, to be honest. AbstractWorkflow is a 
very ugly class with some pretty nasty code (sorry Pat!)

We definitely will be looking at refactoring it and making it much more 
straightforward to extend and enhance for the 3.0 release.

>     I think the codebase is really needing a refactoring, in order to 
> make
> it more object oriented and efficient. Why using objects internally to 
> later
> convert to primitives as return, to get primitives a parametes and 
> convert
> them to objects in order to do the work? Why the ActionDescriptor is 
> not
> aware of the Step? This forces to check all the StepDescriptors, to 
> look
> where the Action is defined. And this kind of things makes the code to
> behave like the doAction, where the Action is known but ALL the actions
> are checked for availability...
>
Well, *Descriptor classes are 'stateless', they just describe 
something, and so I don't think they should ever become 'aware' of 
steps or workflow entries. It's like the relationship between objects 
and classes.

>     But the efforts to make changes and improve must be drived by the
> features, and I haven't found a Road Map for OSWorkflow. Asking the 
> users of
> the workflow for features to be introduced in version 2.5, when this 
> release
> is supposed to be released "soon", wont drive the project in a ordered
> way.
>
Yep, I personally have never been a big fan of 'lets keep adding lots 
of code and features and keep churning out new versions', so I'm the 
wrong person to ask when it comes to some kind of grand vision or a big 
fancy roadmap. As far as I'm concerned, it's a lot more important in a 
real world situation for things to just 'work'. So I like to focus on 
adding things that people actually need, vs adding features for the 
coolness value. By all means, I encourage people to speak up and say 
stuff like 'I wish I could do XXX', it might or might not get done, but 
at least it would give the rest of us ideas and a sense of what 'real 
life' usage people expect and would like.

>     Does Pat and Hani need more "formal" help? How can users become
> active developers, commiters, documenters? Maybe a growing
> community of developers / commiters is needed, and more formal
> patterns to the applied.
>
Hey, if people want to submit stuff, then I'm all for it! I am 
reluctant of having a large number of committers due to seeing how 
detrimental that can be to a project. Does anyone find the current 
approach of submitting patches to jira too 
slow/annoying/inefficient/discouraging? I try to regularly check them 
and commit any useful looking patches. Maybe having jira automatically 
send email to this list when new issues are created would make it 
speedier.

>     The benefits of a Road Map? Pat and Hani would be tackled with less
> feature requirements, and the we (the users) would know when to shout 
> up our
> requirements, and where our support (patches, bug reports or 
> documentation)
> will be more usefull. Successfull OpenSource projects benefit from the
> effort of the developers and users community toward a clear goal, 
> hacking
> the
> code in our sandboxes to fit out special needs would be a waste of 
> time and
> resources.
>
I agree, I'm all for adding things to osworkflow instead of people 
adding it all to their own private trees. On the other hand, osworkflow 
IS meant to be extended, so I'd consider it a success if users manage 
to have neat things plugged in. There is a difference between plugging 
in smoothly vs having to hack at oswf source to get it to behave. The 
former is good, the latter bad.

Hani



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge