Re: [vwrap] The <embed> tag... is the group still interested in LLSD or DSD?

[Vaughn Deluca <[e-mail]>]

Morgaine, vwrap,

 Your proposal sounds good, and  a lot more workable than starting from
scratch.  However you wrote earlier:

> Indeed, in the early days of our IETF effort, we spent months discussing
the
> width of integers in LLSD because there was only one width allowed and it
was
> hardwired in the spec.

What were the reasons to allow onl a single integer type? There must have
been a good arguments for that?

Up til now i saw suggestions for adding more integer types and for adding a
stream buffer type.
I think we should aim for keeping the set of additions as small as possible.
You suggest to add "all the usual integer types and maybe others", what
would those other types be?
Are you thinking of Dzonatas' his stream buffer type, or something else?

The version negotiation system seems to be orthogonal to adding extra types
to LLSD, i think we should  try and reach consensus on the data types
first. It indeed looks like this can be done with very little pain or delay.

-- Vaughn


On Thu, May 5, 2011 at 4:33 PM, Morgaine <[e-mail]>wrote:

> On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca <[e-mail]>wrote:
>
>>
>> So what do you suggest is the way forward?
>>
>
>
> I suggest the following as a way forward with very little pain or delay:
>
>
>    - As other serialization systems have done, add those predefined types
>    that we can easily foresee will be very beneficial to VW applications.  That
>    certainly includes all the usual integer types, maybe others.  We could
>    agree on a useful set of them today, it's not hard.  It wouldn't be perfect,
>    but it would be "our best shot" at supporting what the immediate future
>    requires.  It would give our types system added *flexibility*, and its
>    extra *efficiency* would improve the performance of our binary
>    serializations.
>
>
>    - As Carlo has suggested in the past, add a version negotiation system
>    so that when VW projects find our 2011 set of base types inadequate, they
>    can evolve the types system and negotiate use of a newer one dynamically at
>    protocol initiation time, without needing to come back to the IETF.  This
>    would give us a measure of *extensibility* without needing to make our
>    initial elementary types extensible.
>
>
> - Can LLSD itself be made extensible?
>>
>>
> It can be made extensible, yes, but with this group's track record of
> continually saying "No" even to simple technical advances, I would not want
> to be an advocate for more complex extensible base types.  Instead, I'll
> make do with Carlo's approach, ie. extensibility through negotiating
> alternative versions.
>
>
>>
>> I am all for rigorous design, but i think i prefer actual implementation
>> of an imperfect system over sitting and waiting for an ultimate dream.
>> If we don't get demonstrated commitment for specifying (and implementing!)
>> an alternative, my vote go's to sticking with LLSD, if only to show
>> conclusively were it falls short of our needs.
>>
>>
> Which is why I suggest that we do no more than add those types that we can
> envisage being needed in designs *today*, without speculating about
> tomorrow.  Such flexibility is the least we can do while pretending to be
> "designing for the future".  If we go forward with a design that *WE KNOW
> FULL WELL* is inflexible and inefficient through providing only a single
> integer type, then we cannot pretend to be designing for the future at all,
> it's designing for a specific application today.
>
>
>>
>> I am all for rigorous design, but i think i prefer actual implementation
>> of an imperfect system over sitting and waiting for an ultimate dream.
>> If we don't get demonstrated commitment for specifying (and implementing!)
>> an alternative, my vote go's to sticking with LLSD, if only to show
>> conclusively were it falls short of our needs.
>>
>
>
> There is no point going through all this IETF effort just to produce a
> protocol that we know is designed for today, without even a nod for the
> future.  It will be obsolete before it's released.
>
> If we did so in ignorance, fine, we would deserve to be ignored by future
> VW designers who will find our design skills so lacking in future vision.
> But we would not be doing so in ignorance.  Others in this group have
> commented on the lack of future proofing in LLSD too, not just myself.  We
> would be rolling out a poor types system with our eyes wide open, despite
> being made aware of its lack of flexibility and extensibility.  Future VW
> designers won't have any sympathy at all, we will be laughed at and
> condemned as knowingly regressive.  And they would be right.
>
> I do not believe that this group is so technically incompetent that we
> can't produce a types system with a measure of flexibility and extensibility
> (through negotiation at least).  What we do clearly suffer from is extreme
> inertia and resistance from some participants with a regressive outlook on
> protocol design, so much so that you're suggesting that we move forward with
> a known inflexible system just because of our people problems here.
>
> Well I can't help that.  I've been doing my bit for pulling the cart into
> the future, despite intense opposition.  That's how engineering advances are
> made, by always designing for tomorrow.  I wish a few more people here would
> help with that.
>
>
> Morgaine.
>
>
>
> ========================
>
>
> On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca <[e-mail]>wrote:
>
>> Morgaine,
>>
>> You observe LLSD is not extendable. Dzonatas argues that the this can be
>> solved at a higher level using XML.  You object that this  entangles the
>> serialisation with basic ADT
>>
>> So what do you suggest is the way forward?
>> - Can LLSD itself be made extensible?
>> -if not, do we have enough commitment in the group to start from scratch?
>> -if not, do the benefits of an absolutely clean engineering solution
>> outweighs the costs of disrupting the already slow progress here? We reach
>> for the sky, but run the risk of over extending our current capabilities.
>>
>> I am all for rigorous design, but i think i prefer actual implementation
>> of an imperfect system over sitting and waiting for an ultimate dream.
>> If we don't get demonstrated commitment for specifying (and implementing!)
>> an alternative, my vote go's to sticking with LLSD, if only to show
>> conclusively were it falls short of our needs.
>>
>> -- Vaughn
>>
>>
>> On Thu, May 5, 2011 at 12:59 AM, Morgaine <[e-mail]
>> > wrote:
>>
>>> I have no idea what either of the last list two posts meant.
>>>
>>> I tried to interpret the preceding post as best I could and to find room
>>> for technical discussion, but clearly the attempt has failed.
>>>
>>> I'll leave it at that.
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>> ===========================
>>>
>>>
>>>
>>> On Wed, May 4, 2011 at 11:41 PM, Dzonatas Sol <[e-mail]>wrote:
>>>
>>>> On 05/04/2011 03:21 PM, Dzonatas Sol wrote:
>>>>
>>>>> Actually, I invented one tag called <embed> that does all the above
>>>>> already, so how about the predefined embed'ed data type instead of endless
>>>>> extensibility?
>>>>>
>>>>>
>>>> On that NOTE: any more needed extensibility is transistioned into
>>>> capabilities.
>>>>
>>>> Whereas, capabilities means more resources (as dynamic extensions grow);
>>>> therefore, this requires minimization of number of connections instead of
>>>> one connection per resource. Thus, that proportion leads into the reason for
>>>> combined/bundled queries that I have already mentioned and implemented, as
>>>> maximum # of connections are too easily reached without such mechanism.
>>>>
>>>>
>>>> --
>>>> --- https://twitter.com/Dzonatas_Sol ---
>>>> Web Development, Software Engineering, Virtual Reality, Consultant
>>>>
>>>> _______________________________________________
>>>> vwrap mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/vwrap
>>>>
>>>
>>>
>>> _______________________________________________
>>> vwrap mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/vwrap
>>>
>>>
>>
>