Re: New MWABP draft. (LC candidate ?) / comments

thanks. inline.

On Mon, Jun 22, 2009 at 11:07 AM, Eduardo Casais <casays@yahoo.com> wrote:

>
> Status
>
> --------
> This document was produced by a group operating under the 5 February 2004
> W3C Patent
> Policy. This document is informative only.
> --------
>
> To avoid confusion, perhaps the following text would be suitable:
>
> The present document was produced by a group operating under the 5 February
> 2004 W3C
> Patent Policy; the latter document is informative only.
>
> Although, is it true that the patent policy document is informative only?
> Is it not
> binding upon the work of the various W3C groups?
>
> will do.

>
>
> 3.1.1.1
>
> Complement
> --------
> See BP1 [COOKIES] Do not rely on cookies being available for more cookie
> related
> caveats.
> --------
> as follows:
> --------
> See BP1 [COOKIES] Do not rely on cookies being available for more cookie
> related
> caveats and approaches to work around their unavailability.
> --------
>
> i don't think this adds a great deal, but happy to include.

>
>
> 3.2.1.2
>
> -------
> JSON parsers are approximately x10 slower than eval and may be impractical
> for large
> datafeeds
> -------
> Just to clarify: what is meant with a "large data feed"?
> a) is it a reference to a limit on the size of the JSON fragments that are
> passed to
> the terminal (i.e. the parser cannot handle large objects)
> b) or a reference to the throughput of the feed to the terminal? (i.e. the
> parser
> cannot handle the numerous and frequent arrivals of JSON data efficiently)
> >From the discussion on the speed of Javascript parsers, I presume it is
> (b).
>
> it's (a), the basic computational effort of parsing in a javaScript parser
compared with using the natively implemented eval(). So there isn't a hard
number for "large data feed" it's about whether it causes a user perceivable
difference. Developer feedback was that for certain applications, there was
a window of data feed size (I could probably pull a rule of thumb number for
this, but I'm not sure how much value it has in the general case) where
using a parser made the app more or less unusable but switching to eval
meant performance was acceptable.

>
>
> 3.3.3.1
>
> The following practice
> -------
> These notices should be provided when the user first accesses the Web
> application,
> on first access to user information, or in help pages.
> -------
> means that a valid way to implement it is to let the application access the
> personal
> information, just mentioning that such accesses are performed in some
> hidden corner
> of the help menu. Is this what is intended?
>
> PIM security shouldn't be implemented at the application level anyway, it's
the responsibility of the platform / API providers to get that right.

>
>
> 3.4.6
>
> Well, the discussion on sprites still leaves me wondering whether we are
> trading a
> reduction in network latency (less HTTP transactions to retrieve images)
> for an
> increase on terminal CPU latency (because of interpreting more complex CSS
> and
> rendering images in more complex ways), so that the net gain might not be
> as
> substantial as suggested. There were enough hints in Stephanie's message
> (and in
> other places as well) that sprites require careful optimization on the
> client side,
> so all this nourishes my suspicions. Furthemore, the effects of caching
> reduce the
> amortized cost of not using sprites (also in the light of 3.5.1). So once
> again,
> where are the figures?
>
> Note that even if latency is not reduced significantly, this does not mean
> that
> sprites are useless: reducing the _number_ of I-O requests to handle is a
> benefit
> for _servers_ (and one that gets mentioned by developers), while sprites
> might have
> advantages for content management (I will not attempt to settle the
> discussion
> between Stephanie and Rotan on this point). All these could make for best
> practices,
> though not for the reduction of end-user latency.
>

To these last points the benefits of number of IO requests, etc I don't
think these are significant. End-user latency is the key motivator for
spriting images. I know that they are used extensively in the development of
all the mobile Web applications I've been involved with, but if we want
concrete figures somebody needs to volunteer to do that experiment.

>
>
>
> 3.4.10.2
>
> "unneeded cookie information" => "superfluous cookies".
>
> will do.

>
>
> 3.4.11
>
> -------
> Keep the DOM size below 10MB to avoid browser crashes.
> -------
> Just curious: is this limit based on experience reports?
>
> This is the WebKit limit and observed empirically on iPhone.

>
>
> 3.5.2.2
>
> With pre-fetching
> -------
> Preload Probable Next Views: If the flow of a particular Web application
> means
> certain paths through the application are more probable, preload these
> views so
> they can be displayed immediately when the user requests them.
> -------
> the difficulty is when to do it.
> a) It increases start-up time when done during application initialization
> (against
>   3.5.1).

Well you wouldn't start preloading until the initial view were displayed,
that should be obvious.

>
> b) It increases latency when done during a user-originated request (against
> 3.5.2
>   itself).

Yes.

>
> c) When done in the background, at times when the user is interacting with
> the
>   application but not the network, it goes against 3.4.4 and might raise
> issues
>   with 3.3.1).
> Some additional recommendation or warning is needed here.
>

i can add a note if you like, but there are trade-offs in all these BPs and
if we attempt to explicitly call out every one of them then the document
will be unreadable. In this case my feeling is that the trade-offs are
sufficiently obvious to omit.


>
>
>
> 3.5.8.1
>
> Editorial:
> -------
> Data updated on one devices should be viewable consistently on other
> devices.
> -------
> should be "updated on one device".
>
will do.

>
>
>
> 3.6.1.2
>
> Two remarks:
> a) The header field "Accept-Charset" is relevant and important as well.
> b) Various browsers (notably IE Mobile and Opera) send proprietary header
> fields
> containing information about the device capabilities. The
> Microsoft-specific fields
> are of particular relevance, as they are well-established and recorded in
> the IANA
> provisional HTTP registry and in its associated RFC4229.
>

Do you think this is worth calling out explicitly ? Please provide some
proposed text.

>
>
>
> 3.6.2.2
>
> I always have some difficulties to include technologies, such as DCCI and
> OMA DPE,
> which are just being standardized, have few, if any, implementations, and
> for which
> no experience is available to derive best practices.
>
> I suggest separating DCCI and DPE from the Javascript and CSS bullet points
> (the
> latter are "available to the developer", the former are not), and prefix
> them with
> the following sentence:
> -------
> Other emerging techniques that may become relevant to the developer are:
> [... put here DCCI and DPE bullet points ...]
> -------
>
i agree. will do.

>
>
>
> E.Casais
>
>
>
>
>
>