Improved viewer and script communications (Re: [sldev] Puppettering Branch)

Dahlia Trimble dahliatrimble at gmail.com
Mon Jun 9 11:11:26 PDT 2008


I dont see why the requested functionality couldn't work with existing
channels, or am I missing something here?

On Mon, Jun 9, 2008 at 10:47 AM, Teravus Ovares <teravus at gmail.com> wrote:

> I note that we can argue exactly what the RFC means until we're blue in the
> face.  Ultimately what matters is how the libraries the client uses handle
> it.
>
> From the referenced definition of the words:
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
>
> 2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
>    definition is an absolute prohibition of the specification.
>
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
>
> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>    there may exist valid reasons in particular circumstances when the
>    particular behavior is acceptable or even useful, but the full
>    implications should be understood and the case carefully weighed
>    before implementing any behavior described with this label.
>
> 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the same item.
>    An implementation which does not include a particular option MUST be
>    prepared to interoperate with another implementation which does
>    include the option, though perhaps with reduced functionality. In the
>    same vein an implementation which does include a particular option
>    MUST be prepared to interoperate with another implementation which
>    does not include the option (except, of course, for the feature the
>    option provides.)
>
>
> So, given this, the word 'MAY' is optional.   SHOULD is almost always.
> SHOULD NOT is almost never.
>
> Best Regards
>
> Teravus
>
>
>  On 6/9/08, Tateru Nino <tateru.nino at gmail.com> wrote:
>
>> Actually it is not a mandate. A mandate would be a MUST NOT. This is a
>> SHOULD NOT, specifically:
>> "A single-user client SHOULD NOT maintain more than 2 connections with any
>> server or proxy. A proxy SHOULD use up to 2*N connections to another server
>> or proxy, where N is the number of simultaneously active users."
>>
>> I've got personal knowledge that the author did not intend the above to
>> apply to situations like this. For the substrate to MSIE, however, it is
>> entirely appropriate. Also, the above only applies to persistent
>> connections, not non-persistent connections (applying the same guideline to
>> non-persistent connections would cause problems that this guideline is
>> intended to avoid).
>>
>> Just because you're doing HTTP, doesn't make you a part of the Web, and
>> connection considerations in Web architecture over HTTP are different to
>> other architectures over HTTP.
>>
>>
>>
>>
>> Teravus Ovares wrote:
>>
>>> I also note, that according to Microsoft's kb article:
>>>  "The HTTP 1.1 specification (RFC2616) mandates the two-connection limit.
>>> The four-connection limit for HTTP 1.0 is a self-imposed restriction that
>>> coincides with the standard that is used by a number of popular Web
>>> browsers."
>>>  You can read the article here:
>>> http://support.microsoft.com/kb/183110
>>>  You can read the RFC here:
>>> http://www.faqs.org/rfcs/rfc2616.html
>>>  Best Regards
>>>  Teravus
>>>
>>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/9c2a20da/attachment.htm


More information about the SLDev mailing list