But I already did notice that there are drawbacks with mandatory names ... the
single value Edgent suppliers for example ... here I need to set a name, even
if it's not needed and implicitly given by the pipeline I am plumbing together
Am 19.02.18, 16:39 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
I agree ... we should make it mandatory.
Let's hear what the others have to say.
Am 19.02.18, 16:23 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
I think I’m generally +1 on this, though I think *optional* names may
just make it harder / less predictable to use these objects. Why not just
require names? This also relates to the usability of a batch request/response
object, and the ability to offer a get-item-by-name accessor, instead of just
Since a ResponseItem has an associated RequestItem, there seems to be
no need for it to have it’s own name (regardless of memory impact). Though for
convenience, it could still have a getName() accessor (that was just
> On Feb 19, 2018, at 9:11 AM, Christofer Dutz
> Hi all,
> I’m currently whipping up a first POC for usage on a real machine
(Not just our companies Christmas tree) ;-)
> While at it, I did notice again what I had noticed a few times
before: It would be cool if we could assign a “name” or “alias” to a request
> With this for example I could auto-serialize a read-response with
meaningful names. I would make it optional, but I think it could be helpful.
> Also I wouldn’t assign it to the response items, but just the request
items so the amount of memory used would be minimal.
> What do you think?