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

Dzonatas Sol <dzonatas@gmail.com> Sat, 07 May 2011 17:23 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 7A50AE06C0 for <vwrap@ietfa.amsl.com>; Sat, 7 May 2011 10:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 AW9-EJ9effbS for <vwrap@ietfa.amsl.com>; Sat, 7 May 2011 10:23:07 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF90E0691 for <vwrap@ietf.org>; Sat, 7 May 2011 10:23:07 -0700 (PDT)
Received: by pwi5 with SMTP id 5so2434270pwi.31 for <vwrap@ietf.org>; Sat, 07 May 2011 10:23:06 -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=oCKjT7IhLE9QEEMJDT7YOJiw9oCBgTfhXdXB/BDwDvg=; b=Rp7OJl850mM5W4gkgJuOnb48NX/aPzYNk857GMk8mhRugCcx+HoI8eoA4dwPClEUh8 PDWVBC9VSURI0DDuZGmsEYeinQq97mXHSkJZDd4c98UUDuINxPHzafFbMxE+wdSXRBfL FIEKw27s9HcMfXMuyH/WUEorCtEp8Oy6HQt6c=
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=mCXVYLEb4vIe65u9O1pK3dJL2jYwBoo1LSxdLCT7pf51zlVY7J5hWU5yEPsW5u28Xb b9yckd3BFir6Org++DTmz9VVvgAOkcyd/hnx1ClDydRfzoLDXJcYhJ83SvwE/Cwo0jPL zkpEteDrikveI99yTb+CRGp7VawQdWSiM9OIQ=
Received: by 10.142.143.15 with SMTP id q15mr2570296wfd.60.1304788986594; Sat, 07 May 2011 10:23:06 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id f4sm2930901pbs.36.2011.05.07.10.23.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 10:23:05 -0700 (PDT)
Message-ID: <4DC57FBD.6010103@gmail.com>
Date: Sat, 07 May 2011 10:22:05 -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> <4DC15504.3090503@gmail.com> <BANLkTikay4xhQoZs2L0uRLSXgUMfCE9yfA@mail.gmail.com> <4DC160F0.1030201@gmail.com> <BANLkTikTYpLHM=GAeGAVfufqZ5XT0FSAzw@mail.gmail.com> <BANLkTi=kjBSuMjPcgfXTUvZ3iwmS1bN50Q@mail.gmail.com> <4DC17704.3020201@gmail.com> <BANLkTimpGpNrkE3WUdurduqrVumocDRwfQ@mail.gmail.com> <4DC1824B.6040609@gmail.com> <BANLkTi=hhsiDs=fdZRsthp_+5Hs+pR4L6A@mail.gmail.com> <4DC1956A.5020204@gmail.com> <BANLkTik8rnsKP4xq+Gj5G4dsG=UOVnkNSQ@mail.gmail.com> <4DC1A8C9.9090406@gmail.com> <BANLkTikkOS34CC+ML0JNJgHDoRqbs9rY9w@mail.gmail.com> <4DC1D165.7010705@gmail.com> <4DC1D5FC.6040608@gmail.com> <BANLkTik81Eht3NTdLXXmgqOWvjc2s_KBnw@mail.gmail.com> <BANLkTi=-heHa35w43te0ba8NufkT+MP+CQ@mail.gmail.com> <BANLkTin6ExR7+xpodbtoTAS_4WyhUXL92Q@mail.gmail.com> <BANLkTikjKib79_rLR_s2X=X-ss-+V_yw+w@mail.gmail.com> <BANLkTim4aY7oNALbOfZ2V-htivVmQJZDiA@mail.gmail.com> <BANLkTi=7MDUAfjJb697uRwrrxB-4v5fQ3A@mail.gmail.com>
In-Reply-To: <BANLkTi=7MDUAfjJb697uRwrrxB-4v5fQ3A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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: Sat, 07 May 2011 17:23:08 -0000

That is why there are differences in transmit type and expect type. That 
is not obvious unless without source code. Self-documents that 
transistion possibility.


On 05/07/2011 12:45 AM, Dahlia Trimble wrote:
> I believe python supports very large integers. Try this in your python 
> interpreter:
>
> >>> bigint = 2**(2**16)
> >>> print bigint
>
> I first became aware of missing integer types in LLSD when I was 
> coding the event queue messages to support group chat in 
> OpenSimulator. It seems that "region handles" are 64 bit integers in 
> the LL protocols but are encoded as a base64 encoded binary blob in 
> LLSD as LLSD has no support for integers larger than 32 bits. I 
> suspect that changing LLSD to have larger integer types might create 
> some compatibility issues with existing implementations that expect to 
> use the binary blob.
>
>
> On Fri, May 6, 2011 at 9:18 AM, Joshua Bell <josh@lindenlab.com 
> <mailto:josh@lindenlab.com>> wrote:
>
>     On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca
>     <vaughn.deluca@gmail.com <mailto:vaughn.deluca@gmail.com>> wrote:
>
>
>         What were the reasons to allow onl a single integer type?
>         There must have been a good arguments for that?�
>
>
>     IIRC, some of the languages we wished to support (Python comes to
>     mind) did not have support for integers larger than 32-bits.
>     ECMAScript doesn't have integer number types at all only IEEE 754
>     64-bit floats; if you constrain the input and output to 32-bit
>     integers it can represent those accurately, but not 64-bit integers.
>
>     If you look at the history of LLSD, it started with 3
>     serialization formats that explicitly specified the type of values
>     - XML, binary, and "notation" - a compact text serialization
>     intermediate in size between binary and XML. The IETF drafts
>     dropped notation and added JSON. The JSON serialization was
>     "lossy" as LLSD describes types and values that don't exist in
>     JSON (Integer, Date, UUID, NaN, Infinity, etc). By design, though,
>     the type conversions described in the LLSD Draft accommodate e.g.
>     by serializing a Date as an ISO 8601 string, which when
>     interpreted as a date by the receiver results in the original Date
>     by the string->date conversion rules. (I don't know if we had
>     resolved every issue with JSON serialization; certainly,
>     discussion about edge cases on this list never made it into a draft).
>
>     As far as adding new types: I believe there was the belief that
>     this could be accommodated by defining an "LLSD2" at some point in
>     the future with a distinct MIME type for serializations (e.g.
>     application/llsd2+xml); unlike the Web, content negotiation over
>     HTTP was assumed to be functional within VWRAP interoperation.
>     Therefore, there was no push to ensure LLSD "v1" was internally
>     extensible or comprehensive for all imaginable scalar/structured
>     types.
>
>     Anyway... if contributors have implementation of abstract data
>     type systems that share characteristics with LLSD and are thinking
>     about adding additional scalar/structured types, they should look
>     at the issues with both implementation languages and serialization
>     formats.
>
>     -- Josh
>
>
>     _______________________________________________
>     vwrap mailing list
>     vwrap@ietf.org <mailto:vwrap@ietf.org>
>     https://www.ietf.org/mailman/listinfo/vwrap
>
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>    


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