Hi Dale,

for a test I simply added "name" as name for the item and it seems to work 
nicely without increasing complexity of the API.

However splitting up into Single and Batch is difficult as for single we would 
have to split up to Singe, Array and Batch. Which blows things up quite a bit.

I really think that it would be helpful if we all managed to spare some time 
and collaborate on the API thing (Even if it's via some online tool).

I doubt too many will be going to Montreal. However that would be THE 
opportunity to meet.


Am 19.02.18, 18:38 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:

    Right a name isn’t really required for the single-item-request case.  Not 
sure that requiring one is that big of an imposition though and I suspect it 
will make an app clearer even in that case.
    I know some of this was hashed over a while ago but maybe there should be 
different classes for single vs multi-item requests?  Multi-item requests are 
always composed of named items.  Single-item requests… never/always/optional?   
Separate classes would eliminate the “noise” of the presence of 
getRequestItems() and getNumberOfItems() for single-item users and the 
“inapplicability” of getRequestItem() for multi-item requests.
    > On Feb 19, 2018, at 10:56 AM, Christofer Dutz <christofer.d...@c-ware.de> 
    > 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 ...
    > Chris
    > Am 19.02.18, 16:39 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
    >    Hi Dale,
    >    I agree ... we should make it mandatory.
    >    Let's hear what the others have to say.
    >    Chris
    >    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 
get-item-by-meaningless-index :-)
    >        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 
    >        — Dale
    >> On Feb 19, 2018, at 9:11 AM, Christofer Dutz <christofer.d...@c-ware.de> 
    >> 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 item.
    >> 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?
    >> Chris

Reply via email to