n image copying library would be nice, I think a better way to do
it would be to
have some sort of library composed of building blocks, such that each driver
could make use of
common functionality while still tailoring the operation to the quirks of the
particular drivers.
Best Regards,
Solly
Apologies for coming to this discussion late...
On 4/22/14 6:21 PM, "Jay Pipes" wrote:
>
>Right, a good solution would allow for some flexibility via multiple
>transfer drivers.
+1. In particular I don't think this discussion should degenerate into
zero-copy vs. pre caching. I see both as poss
On 4/16/14 10:00 AM, "Dan Smith" wrote:
>> There may be some consistency work needed. I spent some time/text in
>> justification around no security impact in a spec. I was guided
>> specifically that None was a better statement.
>
>I think you're referring to me. What I said was, you went int
I love that we are getting feedback from deployers/operations/etc. Thanks
to all who have spoken up in support from that perspective.
On 4/16/14 4:02 AM, "Day, Phil" wrote:
>>
>They are intended to be high level designs rather than low level designs,
>so no they don't have to include all of th
I like this plan as it addresses my primary concern of getting deployments
comfortable with the transition.
We don't mention SDKs in the plan. It seems like getting at least one SDK
to use v3 would provide us additional data in the transition. There is
clear risk associated with that, but it may
+1
If we don't recognize that v2 is going to be around for a long time, have
some growth/require support we are kidding ourselves. Establishing a
timeline to deprecation prior to release of v3 is not the right decision
point. We should determine if v3 is ready for primetime, be willing to
suppo
