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

[Carlo Wood <[e-mail]>]

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]>