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

[Teravus Ovares]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080609/265eab98/attachment-0001.htm