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

[Dzonatas Sol <[e-mail]>]

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 <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>     On Thu, May 5, 2011 at 11:46 PM, Vaughn Deluca
>> <[e-mail] <mailto:[e-mail]>> 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
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>
>


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