> On Aug 10, 2018, at 11:55 AM, Robin Sommer wrote:
>
>
> Ok, let's make that change then, I think removing relay() will help
> for sure making the API easier.
If relay is removed how does a script writer efficiently get an event from one
worker (or manager)
to all of the other workers?
—
On Fri, Aug 10, 2018 at 10:24 -0500, Jonathan Siwek wrote:
> Or is it a matter of "if a user needed it for something, then it's
> available" ?
Yeah, including matching expectations: if there's a
"bro/cluster/worker" topic, I'd expect I can publish there to reach
all the workers (from
On Fri, Aug 10, 2018 at 8:29 AM Jan Grashöfer wrote:
> > Let me try to phrase it differently: If there's already a topic for a
> > use case, it's better to use it. That's easier and less error-prone.
> > So if, e.g., I want to send my script's data to all workers,
> > publishing to
On Thu, Aug 9, 2018 at 1:29 PM Robin Sommer wrote:
> > (1) enable the "explicit/manual" forwarding by default?
>
> Coming from that assumption above, I'd say yes here, doing it like you
> suggest: differentiate between forwarding and locally raising an event
> by topic. Maybe instead of adding
On Fri, Aug 10, 2018 at 15:22 +0200, Jan Grashöfer wrote:
> different purposes. If that is still a design goal, it feels like the
> structure of a cluster could be more volatile than it used to be.
It is, and we have some of that, and I think it fits in with the
discussion here too. In my
On 08/08/18 17:48, Robin Sommer wrote:> I think it's safe to assume we
have the cluster structure under our
> own control; it's whatever we configure it to be. That's something
> that's easier to change later than the API itself. Said differently:
> we can always adjust the connections and topics
On Fri, Jun 15, 2018 at 9:38 PM, Vlad Grigorescu wrote:
> Even if it's not widely used, I think it'd be a nicer user experience if
> we were to ship a script that handled dhcp_message, and raised the old
> events. We could mark the old events as deprecated, and remove them in the
> next version.
