Hi Maciej, thanks for your old and your new comments. Do you remember if I answer all the old ones? Answers in line
On Sun, Jul 22, 2012 at 3:45 PM, Maciej Swiderski <mswiders@redhat.com> wrote:
Mauricio, great job with all the wiki's
about it! it really helps to follow the design.
As it comes for comments, most of them have already sent to you
like a month ago. In addition to those I have few more:
- is task definition service mandatory - I mean we already have
definition of a task as userTask in bpmn2 so don't see a reason
why we need to have definition once again stored on task server?
Good point, and the answer is: It depends. the UserTask information is just a dimension of the information that can be stored about a Human Interaction. As you well mention this information is already inside the BPMN2 schema. We can decorate this information with additional information if we want, and we can share those definitions between different processes. Think about it as a UserTask template with some predefined values and expressions. Is it mandatory? to have the same functionality that we have today, no, it is not. But I would love to have the place holder to implement the logic if we need it in the future. When you start thinking about the form builder, sub tasking, questionnaires, etc inside the context of the task, it will probably make more sense to have a place where we can store that extra information that is not related in any way to the process definition.
- seam transactions - does that mean we have tight dependency on
seam framework? do we want that? I recall that some time ago we
tried to remove such dependency... and wondering how that would
look like in other application servers, etc....
Ok, I wasn't suggesting seam transactions, I was suggesting seam persistence, which basically is doing all the dirty work that we are doing for supporting different "Persistence and Transactions" configurations. Think about seam persistence as Spring Persistence, if we adopt Spring, that dependency will be required. The good thing about Seam Persistence is that gives us all the glue to support Spring and Weld together under the umbrella of the CDI specification. Chase me in the chat, if you want to talk more about this topic, because I know that sometimes we think that seam is more than what we it really is.
- backward compatibility - will we have any layer that will
provide old way to the new task server or we consider this as one
time switch?
Yes, but I will be working in parallel to implement the same set of features using the new proposed architecture. Give me a week and we can think about how we can support or propose the jump from one to the other. Because we are re-structuring the interfaces, at some point the migration will need to happen, it doesn't matter the code behind the interfaces.
Maciej
Cheers, and thanks again for the comments!
On 19.07.2012 11:25, Mauricio Salatino wrote:
Hi Guys,
I've made a brief about the refactorings that I'm planning to
do based on the experiments that I was doing based on the
concepts and requirements for a Human Task module that we all
know.
I've published this wiki page summarizing the main points
that I'm targeting to cover on this refactor, so I appreciate
any feedback remarks, questions.
Let me know if you don't understand something or if you have
doubts about this approach. In my perspective this looks clear,
simple, flexible as it should be :)
But I'm open to any constructive criticism.
As mentioned in the document, you can download a working
version of this component from the following URL if you want to
see how the APIs feel and how the internals are working: https://github.com/Salaboy/human-task-poc-proposal/
The next step after the feedback is making it real :)