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

Dzonatas Sol <dzonatas@gmail.com> Sat, 07 May 2011 18:06 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 AF1AAE0707 for <vwrap@ietfa.amsl.com>; Sat, 7 May 2011 11:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[AWL=-0.387, 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 iJEDV5X6-UPO for <vwrap@ietfa.amsl.com>; Sat, 7 May 2011 11:06:14 -0700 (PDT)
Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id D6CDAE071F for <vwrap@ietf.org>; Sat, 7 May 2011 11:06:14 -0700 (PDT)
Received: by pxi2 with SMTP id 2so2535465pxi.38 for <vwrap@ietf.org>; Sat, 07 May 2011 11:06:14 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lOJKohLD9sh9cCfKaHVWD0UwkYjBX167BxHNOw9gieM=; b=JDRBfPjHnlxVKmpWtS0mwonYO9UktKtDwH+7giBOQq3h3b4psgZAIaSQxdsdHVUvc0 mNULfC5J3eTjP3yOWQ8+ZiChE8yc+D8wcgb9zVEernzgEEuEIb3lebk4FLBJAW73gEVS qgqE+BSitUFKucqfuSwDRbGBT9wgbO7jaq55k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=R89PJR5GTKaWYTaYpu32drCU/xo5+X4q7rlR0xLIJPiNzTBWfxb3L8nqVH9yH9gOfS PpCpQgEW0jPL834zq8LY5MQ5UJfH/VMlCgLeKaxklfC34yo8S+ebrPRaR/eKdbx7qk8B uJDuiCWPtfA2YAISbMuWMjnwFnSu3BKuySJBs=
Received: by 10.68.47.2 with SMTP id z2mr1591309pbm.327.1304791574307; Sat, 07 May 2011 11:06:14 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id l3sm2946442pbq.75.2011.05.07.11.06.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 11:06:13 -0700 (PDT)
Message-ID: <4DC589D9.3070705@gmail.com>
Date: Sat, 07 May 2011 11:05:13 -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: Dzonatas Sol <dzonatas@gmail.com>
References: <BANLkTi=g9T5q5bVgytpxRxuE=Oc9iG2F9w@mail.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> <4DC57FBD.6010103@gmail.com>
In-Reply-To: <4DC57FBD.6010103@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: vwrap@ietf.org
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 18:06:15 -0000

To answer the outstanding question,

6 million lines of code and each of them were documented in comments. I 
simply said to the outsourcer there is the problem and figure every 
comment costs $1. How much is it to hire somebody to update one line of 
code plus one comment?

I didn't get the job, yet the the outsourcer did! Amicable.


On 05/07/2011 10:22 AM, Dzonatas Sol wrote:
> 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