On Thu, May 5, 2011 at 7:32 AM, Vaughn Deluca <vaughn.deluca@gmail.com>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 <vaughn.deluca@gmail.com>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 <morgaine.dinova@googlemail.com>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 <dzonatas@gmail.com> 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
>>> vwrap@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vwrap
>>>
>>
>>
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>