1 2 Previous Next 18 Replies Latest reply on Apr 7, 2009 11:15 AM by tom.baeyens Go to original post
      • 15. Re: jBPM 4 Emails Sync vs Async
        bradsdavis

        I dont see the benefit of limiting the email producer to one email.

        To code that in jbpm 3 would mean creating a dynamic fork, and forking over the email node multiple times, or creating a loop in the process and looping over for each person.

        Not only is this inefficient [multiple forks or looping would produce a lot more records in logging, more records for tokens, etc] versus just allowing the email node to produce multiple emails, it is also messy looking in the process definition.

        If we get a generic service for sending email for free, why not? It is free, and it allows much more flexibility.

        • 16. Re: jBPM 4 Emails Sync vs Async
          bradsdavis

           

          also, MailSession doesn't try to be a generic interface for sending emails. it should be limited in scope to only the jBPM process integration use cases.


          When you write something to intentionally limit the scope, some client will inevitably need the functionality that you are limiting. If you write something that is open and flexible, clients will find uses for it that you never even thought of.

          With that in mind, if both cost the same as far as time, I am just saying side with the flexible approach rather than the limiting approach.

          • 17. Re: jBPM 4 Emails Sync vs Async
            tom.baeyens

             

            "bradsdavis" wrote:
            I dont see the benefit of limiting the email producer to one email.

            To code that in jbpm 3 would mean creating a dynamic fork, and forking over the email node multiple times, or creating a loop in the process and looping over for each person.

            Not only is this inefficient [multiple forks or looping would produce a lot more records in logging, more records for tokens, etc] versus just allowing the email node to produce multiple emails, it is also messy looking in the process definition.

            If we get a generic service for sending email for free, why not? It is free, and it allows much more flexibility.


            this MailSession does not limit the jpdl email language features that we want to build on top of it.

            we could still have something like eg

            <mail to-groups="sales-dept, #{claim.type.department}" send-individually="true">
             ...
            </mail>


            and internally, the mail activity can translate that to first obtaining all users to which this email is to be sent. and then send a mail with the MailSession for each user that is supposed to receive a mail.

            the main point i try to make is that the jpdl attributes and behaviour is decoupled from the MailSession interface.

            buiding out the jpdl language attributes is the biggest challenge imo. we should not introduce attributes lightly. after we release GA, we cannot just remove, change or rename attributes.

            • 18. Re: jBPM 4 Emails Sync vs Async
              tom.baeyens

               

              "bradsdavis" wrote:
              When you write something to intentionally limit the scope, some client will inevitably need the functionality that you are limiting. If you write something that is open and flexible, clients will find uses for it that you never even thought of.

              With that in mind, if both cost the same as far as time, I am just saying side with the flexible approach rather than the limiting approach.


              i'm differentiating between MailSession and the jpdl features.

              MailSession is an api that mainly should be used by our jpdl implementation intenally.

              jpdl features documented in the userguide must be stable. so that's why i want to go slowly on that front. i am ok with adding lots of jpdl features and only documenting them in the developer guide. consider this kind of incubation system inside of jbpm. the ultimate target of jpdl is that it will have stable, flexible and lots of features documented in the userguide.



              1 2 Previous Next