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