On Fri, Dec 22, 2017 at 8:19 AM, Vlad Rozov <[EMAIL PROTECTED]> wrote:

It would be developing a plugin in addition to an application as opposed to
doing something directly in the application. Also what they may want to do
may not be general enough or have enough reuse to justify developing a
plugin. Our users typically build applications and not plugins so I would
say most who have this need would not build a plugin but would do this
directly in the application.

The configuration does not prompt the user to return a different DAG and
even with plugins some kind of configuration hint is needed. There is no
formal definition of what the method should and shouldn't do and attempt to
define the method to only construct a DAG and not do anything else is not
only retrospective but restrictive, for example should I not be able to
connect to a syslog server and log something. What you are saying on the
behavior w.r.t the population of the DAG with varying properties and the
like is good practice. Like I mentioned earlier, users have always had full
control of what they want to do in populateDAG method and what DAG they
want to return and the platform does not particularly care what DAG is
returned. It does not enforce nor rely that DAGs returned by multiple calls
to populateDAG be the same DAG.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB