W3C home > Mailing lists > Public > public-appformats@w3.org > December 2007

RE: Comments on: Access Control for Cross-site Requests

From: Igor Netto <Igor.Netto@access-company.com>
Date: Fri, 21 Dec 2007 14:34:01 +0100
Message-ID: <78BEBE845AB46D4789206C4DBB3A969CA5F848@obeex01.obe.access-company.com>
To: <public-appformats@w3.org>

 Hello,
I just want to highlight a small detail that tend to be overlooked (and
usually negletted).

Ian wrote:
> I think that based on the numbers above, it is reasonably 
> safe to assume that the upgrade cycle for servers is slower 
> than the upgrade cycle for clients.
The numbers add very nicely, however there is a dangerous slant in
favour of accessing internet via a desktop PC because:
- Until recently a client (browser) on a desktop PC is the main
interface to internet for most people 
- It's more complex to see what browser and version is used on an
embedded system

More and more people will access internet from embedded devices such as
mobile phones, setTop boxes, car-navigation systems, etc.
The number of mobile phones with high speed internet connection is
raising extremely fast, faster than PC worldwide with equivalent (or
superior) internet connection speed. 
It's necessary to keep in mind that, in future, embedded systems may
have a much larger share of internet access.
Potentially they may be the main interface to internet for billions of
people, especially in emerging markets.

Coming back to my point.
The upgrade time for embedded system is very different from desktop PC.
In most cases it's not possible at all to have meaningful upgrades and
very often people do not bother to upgrade when is possible.
In the worst case the upgrade "schedule" is the same as the life cycle
of the device itself: 18 months for mobile phones (in western Europe), 1
or 2 yars for STBs, and more for other systems.

We can't safely assume that the upgrade cycle for servers is slower than
the upgrade cycle for clients.
That assumption is valid ONLY for clients on desktop PCs.

Widgets, in future, may be more relevant for embedded devices than for
desktop PC.
So better don't forget those poor embedded systems all the time. :)


	Igor.


> -----Original Message-----
> From: public-appformats-request@w3.org 
> [mailto:public-appformats-request@w3.org] On Behalf Of Ian Hickson
> Sent: Friday, December 21, 2007 6:06 AM
> To: Close, Tyler J.
> Cc: public-appformats@w3.org
> Subject: RE: Comments on: Access Control for Cross-site Requests
> 
> 
> On Thu, 20 Dec 2007, Close, Tyler J. wrote:
> > 
> > What evidence do you have that the upgrade cycle for 
> servers is slower 
> > than the upgrade cycle for clients? It's always been my experience 
> > that it's easier to upgrade a server than all its clients. If the 
> > upgrade cycle for clients is indeed longer than it is for servers, 
> > your argument is not persuasive.
> 
> Good question.
> 
> To answer it, I did a survey of about 100,000,000 pages 
> (selected from Google's index, weighted by a rough 
> approximation of what Google algorithmically thinks is most 
> important), to see what the distribution of servers is on the 
> Web (based on the Server: header).
> 
> Note that these numbers count _pages_, not hosts -- a 
> specific host that happens to have many pages in the sample 
> will have the scores proportionally weighted in its favour. 
> This is the same technique as I have used in other studies, 
> e.g. when determining the relative importance of tag names 
> based on class name frequency in the design of HTML5.
> 
> Also note that many servers don't report actual version 
> numbers, and that many servers report quite bogus data in 
> general, which is why the numbers below don't always add up to 100%.
> 
> Looking at the big servers:
> 
>    Apache 2.x: 35% of Apache share
>    Apache 1.x: 23% of Apache share
> 
>    Microsoft-IIS 6.0: 82% of IIS share
>    Microsoft-IIS 5.0: 18% of IIS share
> 
> Both for Apache and IIS, around 20% of the market is running 
> at least one major release behind. Apache 2 came out in 2002, 
> IIS 6 came out about a year later in 2003. (There are only 
> two major browsers in the market. We are assuming here that 
> they would both quickly implement whatever solution was 
> developed for cross-site XMLHttpRequest.)
> 
> Now let's look at the share by version for Firefox and Opera, 
> as given by the reports on marketshare.hitslink.com:
> 
>    Firefox 2.0: 93% of Firefox share
>    Firefox 1.5: 4% of Firefox share
> 
>    Opera 9.x: 98% of Opera share
> 
> Firefox 2 came out about a year ago in late 2006. Opera 9.0 
> came out in mid 2006.
> 
> Thus we see that browsers, over a much shorter time period, 
> upgraded a much broader proportion of their installed base.
> 
> In addition, we have to consider how long it would take for 
> server developers and client developers to actually release 
> software that supported the new features.
> 
> The earlier proposal in this thread involved allowing servers 
> to have custom responses in return to OPTIONS requests, 
> something that relies on CGI scripts being invoked in 
> response to OPTIONS requests. This was not possible in Apache 
> for a long time. That particular issue was originally noticed 
> in August 1996 [1], then reported in May of 1999 [2], and 
> reraised in December 2002 [3], before being fixed in October 
> 2005 [4], more than nine years after the issue was first found.
> 
> On the other hand, the client developers are actively 
> involved in this working group, and are already implementing 
> the new feature in pre-release browsers. It is likely that 
> the features could be available in client browsers very 
> shortly after the spec was ready -- probably in a matter of 
> months for the first browsers to support the feature, not years.
> 
> I think that based on the numbers above, it is reasonably 
> safe to assume that the upgrade cycle for servers is slower 
> than the upgrade cycle for clients. I think it is also safe 
> to assume that client developers would have software ready to 
> be upgraded sooner than server developers would.
> 
> -- References --
> [1] 
> http://mail-archives.apache.org/mod_mbox/httpd-dev/199608.mbox
/%3c9608132318.aa12603@paris.ics.uci.edu%3e
> [2] http://www.mail-archive.com/apache-bugdb@apache.org/msg12727.html
> [3] http://issues.apache.org/bugzilla/show_bug.cgi?id=15242
> [4] http://issues.apache.org/bugzilla/show_bug.cgi?id=15242#c10
> 
> Cheers,
> -- 
> Ian Hickson               U+1047E                
> )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   
> _\  ;`._ ,.
> Things that are impossible just take longer.   
> `._.-(,_..'--(,_..'`-.;.'
> 
> 
Received on Friday, 21 December 2007 14:03:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:24 GMT