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.
Chris
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>
wrote:
>
> 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
getRequestItem().getName()).
>
> — Dale
>
>> On Feb 19, 2018, at 9:11 AM, Christofer Dutz <christofer.d...@c-ware.de>
wrote:
>>
>> 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
>
>
>
>
>
