Re: [vwrap] Status and future of the VWRAP working group

[Vaughn Deluca <[e-mail]>]

Great!, thanks a lot for the constructive input!

I disagree however that this "won't lead to any document any time
soon" It depends on the definition of "document" I might be a while
before it produces an RFC, but I certainly would call the glossary,
wiki pages documenting group consensus, and Definitions "documents".

 I like the wiki idea, (something along those lines was suggested by
Morgaine also). I just requested a password, and it seems i can edit
the Wiki  :) I will put up a VWRAP glossary page later today.

On 3/27/11, Carlo Wood <[e-mail]> wrote:
> On Sat, Mar 26, 2011 at 10:43:49PM +0100, Vaughn Deluca wrote:
>> problem we have is a lack of critical mass, and in particular input
>> from people that have the needed technical background.  And clearly
>> you are one of those that we need badly.
>
> The way I'd like to move forward is anything but producing
> documents fast however; and that seems to be the requirement.
>
> If you want input from me regarding the survival of this group;
> I'd create a wiki that everyone who requests it can edit.
> The first and most important part of that wiki would be a glossary
> with every word that is frequently used in the discussions.
> That list of words should be complete rather quickly, then
> people can add their definitions to it. If two people have
> different definitions then those definitions should be signed;
> Once, for a particular word, everyone has added the definitions
> and/or remarks to the wiki (all on one page per word), we can
> start a discussion on this list on how to reformulize and change
> the definition of that word. Some might have to change their
> semantics, but in the end the goal would be that every word
> has one defintion, used and understood by everyone -- and
> clearly documented on the wiki, with discussion history as
> usual. If a discussion gets completely stuck on semantics,
> then people can just sign (put their name under) the definition
> the want and we'd just count the signatures and pick one.
> After all, it's just semantics and has nothing to do with what
> the protocol REALLY will do.
>
> Only then, we can take the next step; for which I'd also
> use the wiki.
>
> Also, as I wrote in old posts before... I am still CONVINCED that
> we can impossibly create a protocol that will address everything
> that will be needed in the future. All we can do is create something
> that is a good starting point and FOCUS on flexibility: create
> a protocol that can evolve. In order to do that, we need (further
> completely protocol neutral) protocol negotiation for every p2p
> link that is created in the process, which allows such evolution.
>
> The use of XML as basis for a protocol would mean the following:
> 1) It takes overhead, so it's not possible to use it for
>    highbandwidth usage (ie video, or file transfers). But it could
>    do at out-of-band control channel.
> 2) If it's pure XML than we won't have to worry about the
>    implementation of serializing/deserializing as much, although
>    that only really has it's advantages when we will need VWRAP
>    to work for implementations in multiple programming languages
>    before it gets accepted widely. As far as I can see, we will
>    need C# and C++, and most likely C for religious reasons.
> 3) The ONLY benefit that XML has (on top of existing serialization
>    libraries) is that it is extensible: You can add new parameters
>    without confusing old code that doesn't expect it.
>
> Point 3, however, is just a weak attempt to be flexible. Imho,
> it is by far not flexible enough. We'd still need a well defined
> way for the evolving protocol negotiation, and once that is in
> place, we won't really need this feature of XML anymore.
>
> Thus, provided we add "evolving protocol negotiation", we should
> probably choose the serialization/deserialization method based on
> grounds that I can't judge at this point in the design.
>
> So for the near future:
> - Glossary and agreement on definitions of used jargon.
> - Abstract agreement on the use of an evolving protocol.
> - Definition of all possible p2p connection for which serialization is
> necessary.
> - Choice of what serialization mechanism is used where.
> - Abstract discussion (and agreement) of the use of Abelian operators
>   for distributed states and identity authorities (see another
>   old post from me). If we don't do that before anything else,
>   we'd just shoot ourself in the foot.
> - etc
>
> This is no doubt the work of years, and won't lead to any document
> any time soon.
>
> --
> Carlo Wood <[e-mail]>
>