I like the version 3 and 4 (with the nice round idea of the six version), as there is always a need to name the box, so an outline is more often quite mandatory.
The original lib (visio and omnigraffle) could benefit from a nice ‘design refresh’. One missing point however in using those blocks in diagrams, is the fact that there is a need to ‘describe/name/reference’ major ‘conditions or logic predicates’ on message handling inside the box (a route endpoint/node) If you take your example, there is often a need to make an arrow pointing inside the ‘moving part of the switch’ to describe/reference/annotate what destination will be chosen. Having that in mind, will make the overall look and feel of the diagram easier to grasp as there is no more ‘visual disparity’ in comprehension of the overall picture. On Wed, Nov 9, 2016 at 8:26 AM, Francis Vila <fvila...@gmail.com> wrote: > This post contains an offer to contribute towards the diagrams symbolizing > the Camel patters, with 6 different suggested formats > > > > -- > View this message in context: http://camel.465427.n5.nabble. > com/Suggestions-for-new-set-of-integration-pattern- > symbols-tp5789901p5789932.html > Sent from the Camel Development mailing list archive at Nabble.com. >
