Re: ISSUE-237 (Define Mobile Web Applications): What is the definition of a "Mobile Web Application" for the purposes of BP2? [Mobile Web Applications Best Practices]

On Sat, Feb 23, 2008 at 5:04 PM, Sullivan, Bryan <BS3131@att.com> wrote:
>  As an example: say I have a social networking/blogging application. This application allows me to upload pictures/video/text via XMLHTTPRequest to a social networking site that also has desktop browser support (which many of my non-mobile friends use). It also provides an automatically updated view of my blog and that of others to who I subscribe, using standard content syndication and automated web site retrieval methods. Does it really matter if this is a widget-based web application implemented using a web runtime library for various "web" functions e.g. networking/DOM/rendering/interaction, or via a conventional web site browser based upon the very same web runtime library? They are both supporting the same application, using the same technologies, and will benefit from consideration of the same best practices.

Sounds right to me. Sounds like you are describing an application that
is expressed in HTML, delivered over HTTP, uses the DOM and
XMMLHTTPRequest, and is accessed by a "browser" -- well a web runtime
in a different shell.

Are we just hung up on the word "browser" here? I think there is broad
agreement. BPs concern the web application, not the user agent. We are
talking about technologies like HTML, HTTP, DOM, etc. -- which are to
be consumed and rendered by a browser or work-alike equivalent. I
think we all have something like "a browser" in mind, but it's
unnecessary, and impossible, to define "browser" apart from "something
that uses a web runtime library". So we won't.


>  This can't simply be a "turf" issue, where presumably W3C intentionally remains "hands off" widget/MIDP-based web applications for some reason (why? to prevent them from being inhibited by best practices?).

Certainly not, but some things are in scope and some aren't of course.
I do want to return to the issue of what is meant by "widget" and
"MIDP" application again. We've established that we're writing BPs for
content, not user agents that consume them. We're writing BPs for
"XHTML over HTTP and CSS and DOMs and so on", which will be consumed
by some user agent of course that we don't bother to specify. If it's
a native app, a widget-that-happens-to-act-like-a-browser, or a
MIDP-based browser, or a ham sandwich with a WebKit port, doesn't
matter.

So then I am concerned that the words "widget" and "MIDP" keep coming
up. Granted the provision above, MIDP is certainly not in scope for
the MWI. What I think of when I think "widget" (thinking of iPhone
apps?) doesn't seem in scope, but who knows how we're all defining
them. I suggest that there is nothing for us to say about "widgets"
and "MIDP" specifically.

So can we return to the emerging consensus on what we are talking
about? the definitions in other threads are looking fairly good. It's
HTTP and HTML and all that, and is nothing to do with specific user
agents.


If there is dissent there, I think the only way to solve this is to
start giving examples of BPs that are useful, important, but would be
precluded by the emerging definition of what is in scope. I can't
think of any myself but that's me.

It goes without saying that some things must be out of scope, and we
can't operate with a sense that we have to continue to give
consideration to things deemed out of scope. What a BP for web
applications means to what MIDP apps do with CORBA-over-HTTP, we don't
care -- so that we may say more useful and specific things about web
applications. I mean to say, there is in fact a risk of scoping too
broadly, as it will limit ability to write specific, clear, useful BPs
on any particular application.

Received on Sunday, 24 February 2008 00:35:06 UTC