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

Dzonatas Sol <dzonatas@gmail.com> Mon, 09 May 2011 14:29 UTC

Return-Path: <dzonatas@gmail.com>
X-Original-To: vwrap@ietfa.amsl.com
Delivered-To: vwrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7914E0692 for <vwrap@ietfa.amsl.com>; Mon, 9 May 2011 07:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.907
X-Spam-Level:
X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8QHt6wIkbX1 for <vwrap@ietfa.amsl.com>; Mon, 9 May 2011 07:29:56 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9F8E0726 for <vwrap@ietf.org>; Mon, 9 May 2011 07:29:52 -0700 (PDT)
Received: by pvh1 with SMTP id 1so3211417pvh.31 for <vwrap@ietf.org>; Mon, 09 May 2011 07:29:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vnd1vt7iPP+Ke9Q4nBONnXDdNm01ruFdXTXiqjID3eU=; b=YqSEQa89wpgQq/Uv9Wt5pGkwYBiZfYGzshKbafot0tJBACK3SZnC5YhLd6p90XTxSj +ivyigpMh/AUGYBXiZCJEtfpoeovsq0Qrc0A80dICGYOs/cADO5VYE43gTfi0CoUQsiD QKmp9rZ/YmWhfjldFM6BDot+nNFetA28sD24E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Kaf8gCr1hEZhyvXquS/5ucvkptrWunREtbMzNfxnKxYnilbeBHtx9oUtpee8DqHqtC bYT+r3MbLGC0w7JMyyP6oW546ur1nUmoexefabhaKkj1up2EBg7JhwMb6DLGPb20T1b1 VoCcgaUfres/Gl1bSFi3kobwMA9BfnrNiARP0=
Received: by 10.68.66.98 with SMTP id e2mr9790725pbt.447.1304950929744; Mon, 09 May 2011 07:22:09 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id s5sm4136251pba.64.2011.05.09.07.22.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 07:22:07 -0700 (PDT)
Message-ID: <4DC7F856.7020702@gmail.com>
Date: Mon, 09 May 2011 07:21:10 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11
MIME-Version: 1.0
To: vwrap@ietf.org
References: <BANLkTi=g9T5q5bVgytpxRxuE=Oc9iG2F9w@mail.gmail.com> <BANLkTin=tyc+rUy=RvqCJ9r34j90v1nSGg@mail.gmail.com> <4DC6840B.9050203@gmail.com> <201105090012.50031.bobby@sharedrealm.com>
In-Reply-To: <201105090012.50031.bobby@sharedrealm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [vwrap] The <embed> tag... is the group still interested in LLSD or DSD?
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 14:29:57 -0000

On 05/09/2011 12:12 AM, Robert G. Jakabosky wrote:
> On Sunday 08, Dzonatas Sol wrote:
>    
>> If that alone is too hard to comprehend, then your "designing for the
>> future" ignores complete backward compatibility and the many
>> implementations that already exist.
>>      
> -1
>
> Why should VWRAP keep backwards compatibility to anything when we haven't even
> published a standard yet.  The current LLSD spec is a draft and not set in
> stone.  Current LLSD implementations may have to change before this
> standardization process is finished.
>
>    

Standards and implementation is like any 2 step process that remains 
separate. If you give priority to one over the other then it'll cost you 
or someone more. Just because we create the blackbox process to 
accomplish this doesn't mean we ignore each others needs or what has 
been already done.

Why make-up standard for something that never has been implemented? 
You'll probably find you didn't even need the standard and that there is 
something else that already fits your need.

We can't create the blackbox process without implementation.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant