Support for "dropOldest" connection attribute

[jpaulm]

As per @jonnor 's suggestion, I am raising a specific issue for this.

• a connection may have the attribute of "drop oldest" - this means that if a process sends to a connection with this attribute, it will not be suspended, and the oldest IP in the connection will be dropped.
• a "drop oldest" connection will still activate the downstream process

My art work in DrawFBP uses a squiggly line, but feel free to use any (artistic!) notation you like! :-)

[chadrik]

This should probably be handled using edge metadata similar to the proposal for node metadata in #482

[chadrik]

Actually I'd say this is a duplicate of #371. Should we close this?

[jpaulm]

#371 now references this one, but if we close #374 I am concerned that the reference may disappear! It should probably be added explicitly to #371 if you want to consolidate the two... (I am obviously not sure how inter-PR references work!)

[chadrik]

This issue and all references to it will always exist, even if it is closed.

[jpaulm]

Thanks, Chad, but my point is: will it be visible in #371? In this case,
people may take "closed" as meaning that it has been taken care of!

On Mon, May 23, 2016 at 12:25 PM, Chad Dombrova [email protected]
wrote:

This issue and all references to it will always exist, even if it is
closed.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#374 (comment)

[jonnor]

Doesn't hurt to keep it open. In addition to #371 need to define and document the property and values to use for this specific usage.

[jpaulm]

Thanks, Jon - that makes sense to me!

On Mon, May 23, 2016 at 12:47 PM, Jon Nordby [email protected]
wrote:

Doesn't hurt to keep it open. In addition to #371
#371 need to define and
document the property and values to use for this specific usage.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#374 (comment)

[chadrik]

need to define and document the property and values to use for this specific usage

@jonnor, yes, maybe, but first and foremost, it should be up to the runtime to broadcast to the UI the known metadata types that its components/edges/etc support. As @bergie describes in #482 we should "provide a mechanism for runtimes to give [the ui] a metadata JSON schema, so [it] could provide a more specific editor (selects, typed inputs)".

As the number of runtimes hooked up to noflo-ui increases, there will be many runtime-specific metadata values. If the UI does not need to understand them to do its job, then it shouldn't get involved. If noflo can eschew runtime-specific feature requests in favor of open systems, we can avoid protracted debates about what should and shouldn't be included, what the names should be, etc.

In this case @jpaulm would like to see the edge display customized based on this value, so to achieve that the UI would need to know about this edge property (unless we provide the metadata schema the ability to declare a relationship to certain display properties, but that might be overkill). Anyway, I think we should do #482 and #371, including the metadata schema, and if there's still a need for this feature after those, we can revisit it.

[jonnor]

I don't consider to have 'edge display' customized important. Being able to see and edit the values is the key.

I agree that the UI should have no opinion about the contents of metadata. However, for common attributes, it is still desirable to have a convention on what names to use.

[jpaulm]

I assume that currently this feature is just a requirement of the JavaFBP
run-time, so it would be good if we could have the run-time specification
specify a bunch of metadata keys. I don't want this requirement to be lost
in future changes...

However, does anyone visualize supporting multiple run-times with the same
diagram? In this case, we might land up with large lists of keys in a
diagram's metadata, which are enabled by various run-times, sort of like
epigenetics in an organism...

On Mon, May 23, 2016 at 3:24 PM, Chad Dombrova [email protected]
wrote:

need to define and document the property and values to use for this
specific usage

@jonnor https://github.com/jonnor, yes, maybe, but first and foremost,
it should be up to the runtime to broadcast to the UI the known metadata
types that its components/edges/etc support. As @bergie
https://github.com/bergie describes in #482
#482 we should "provide a
mechanism for runtimes to give [the ui] a metadata JSON schema, so [it]
could provide a more specific editor (selects, typed inputs)".

As the number of runtimes hooked up to noflo-ui increases, there will be
many runtime-specific metadata values. If the UI does not need to
understand them to do its job, then it shouldn't get involved. If noflo can
eschew runtime-specific feature requests in favor of open systems, we can
avoid protracted debates about what should and shouldn't be included, what
the names should be, etc.

In this case @jpaulm https://github.com/jpaulm would like to see the
edge display customized based on this value, so to achieve that the UI
would need to know about this edge property (unless we provide the metadata
schema the ability to declare a relationship to certain display properties,
but that might be overkill). Anyway, I think we should do #482
#482 and #371
#371, including the metadata
schema, and if there's still a need for this fea ture aft er those, we can
revisit it.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#374 (comment)