Re: The Wider Web

Ok Richard, a short diatribe...

Let's keep it from getting personal, ok?

It seems like the fundamental issue here is the definition of "the
web". Perhaps this is different from what a "web application" can be,
and how it can be experienced by the user (is a browser really the
only context for the web?).

On Wednesday, February 9, 2011, Rich Tibbett <richt@opera.com> wrote:
> I'm not sure you realize the importance of this rechartering process. I hope it is clear that your stance is again calling in to question the viability of the DAP WG for browser participants, including Opera.
>
> Your long diatribes and eulogizing are not productive without being able to show how your solutions will actually work *on the web*. Assuming we have understood them correctly in the past, this group has decided to drop policy and therefore, by proxy, policy-centric APIs from the charter based on the lack of a technically viable solutions for the one web. Simply putwe are not able to come up with a viable web model for policy within in the next two years in the W3C in a way that is satisfactory for all participants. If someone proposes a magical solution that everybody loves then that would be considered but we're not at all at that point yet.
>
> Please allow actual forward-thinking discussion to take place around the new charter instead of rehashing and revisiting long-settled ancient discussions. You are trying to walk the road already traveled and painting a picture that perpetuates the improper belief that DAP is working on mobile-centric APIs with a focus on locking down access via policies. Nothing could be further from the truth based on our actual technical work. At the same time I'm here to wish WAC every success in its own right as a defacto standards body for industries that are developing APIs that can viably be managed in an apps/widgets environment. The latest specs are not bad considering the context of that objective. However, if you are intent on this route for DAP then this group is clearly not ideologically aligned with your continued participation, we have the same objectives for subtly different environments and we do not need such assistance in putting any user at the mercy of any single participant and their policies, whether in the mobile industry of otherwise, through policy or policy-centric API designs. FWIW, I think that ship doesn't sail unless you can answer the questions such as those I posed a very long time ago: http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0222.html
>
> I'm not interested in producing more pieces of paper to add to a pile. I'm not interested in squashing policy-centric APIs in to a web mould without due diligence on whether that is a good idea (from our discussions in the last 18 months, it's not, by the way). I'm interested in adding more functionality to the web. I hope that everyone reading your mails are offended to be ostracized for trying to do right by users and the web.
>
> Having said all of this, I'm sure you will not fully take in to account what I'm trying to say. That's a feature of discussions that we've had in the past and I expect a long diatribe response. I'm simply saying that your views have been received, processed, considered, discussed, discussed some more and rejected. If you have more technical input on a viable solution that you would like to bring to the group then we can re-open that discussion.
>
> Bryan Sullivan wrote:
>
> I can also say re "Taking vertical solutions and claiming they work
> everywhere doesn't work — it has to actually be true" that forcing
> solutions that only work in horizontal domains onto every market that
> intersects that horizontal domain doesn't work either. Either the depth
> of the horizontal domain needs to be expanded ("wider" in my
> expression), or we face the unenviable situation for developers that
> they will have to support two different API design and security models.
> We owe it to the market (yes I do like that word - it pays my bills) to
> do our best to address this challenge, and not to take the easy way out
> (for us) of running to our separate corners and reassuring ourselves
> that at least we are serving the most important part of the market.
>
> I think the shifts in DAP's focus, especially in the last year, speak
> for themselves re adherence to the course.
>
> We should be careful of claiming what will or "won't be Web technology".
> Adoption defines what "will be", and I would place very strong bets on
> the adoption of the same API design and security design model submitted
> to DAP as BONDI.
>
> We joined DAP with the same objective as joining the MWI and Webapps -
> to aid in the development of standards for context-adaptive Web
> technology. We do have a primary context in mind (mobile), just as
> desktop browser vendors do (general purpose computing platforms). Saying
> that any Web technology has to have no more specialization that is
> necessary for use in a general purpose computing platform clearly draws
> a line between market segments. IMO that is an unnecessary and unhelpful
> distinction, as diversity is inherent, and adaptability to diversity is
> achievable.
>
> --------------------------------------------------
> From: "Robin Berjon" <robin@berjon.com>
> Sent: Monday, February 07, 2011 4:42 AM
> To: "Bryan Sullivan" <blsaws@gmail.com>
> Cc: "Dominique Hazael-Massieux" <dom@w3.org>; "public-device-apis"
> <public-device-apis@w3.org>
> Subject: The Wider Web (was: Rechartering Device APIs & Policy Working
> Group)
>
>
> Hi,
>
> On Feb 2, 2011, at 17:04 , Bryan Sullivan wrote:
>
> Active work in W3C depends upon resources, and we did not expect our
> focus on meeting market needs with an evolution of the JIL and BONDI
> specs to create the environment in which DAP could veer off-course,
> but that is what has happened. Focusing on the market is exactly what
> OMTP did in BONDI (with commercial implementations in the market) and
> WAC has done with WAC 1.0 (also in the market) and WAC 2.0. Our focus
> on serving the market's needs, *now*, limited our resources for DAP
> in the last year.
>
>
> I think that there are several underlying assumptions here that need
> to be surfaced.
>
> First, you mention several times a focus on "the market". By that I
> believe that you mean on "the *mobile* market". The mobile market is
> huge, and sexy, and I love it, but no matter how huge or sexy or loved
> it is still just a subset of the Web. A large, important subset, but a
> subset nevertheless. OMTP did a great job in developing
> mobile-oriented solutions and I hope that WAC meets with success in
> continuing that work.
>
> But you seem to imply that DAP's mission was to continue that work,
> and somehow rubber-stamp if not its specifics, at least its general
> design decisions. I repeatedly stated that that was unlikely to
> happen. DAP has not "veered off course", it has simply been trying to
> address the needs and requirements of its full constituency — the
> complete Web — and not just one subset of it. That may not be the idea
> that you had in mind, but that doesn't put the group off charter.
>
> If this group — or any other — were to specify a solution that were
> unpalatable to the mobile industry (be it for technical, economic, or
> political reasons, at the end of the day it doesn't matter) you would
> oppose it. And you'd be very much right to do so. This universality
> cuts both ways though: solutions that don't work outside of the mobile
> industry — for whatever pragmatic reason — just can't fly.
>
> Designing APIs for the items we have on our charter is child's work.
> Designing them so that they can be used across the Web is the hard
> part. Taking vertical solutions and claiming they work everywhere
> doesn't work — it has to actually be true. Artificially driving a
> vertical solution to Recommendation just creates another piece of
> paper on an already large pile. It won't get adoption, it won't be Web
> technology.
>
> Thankfully, through the hard work of those who have contributed, we
> have found ways of making these APIs work globally. We have APIs that
> are not only device-independent but also work the same in multiple
> security contexts. The added value in terms of library reuse and
> integration of disparate pieces of the system should be obvious.
>
>
> We also supported Web browser vendor participation by accommodating
> (with clearly expressed reservations) their splitting of the APIs in
> the "read" vs "write" (based upon the claimed inability to express
> the write function in their UI paradigms).
>
>
> That is a gross mischaracterisation of the group's history. No one has
> "accommodated" the "browser vendors". There isn't a "claimed
> inability" to express this or that in "their" UI paradigms. This is
> not about browser vendors — this is about designing APIs for the Web.
> In fact, much of what you write above — once removed the distortion —
> are based on decisions made from the input of people who aren't
> browser vendors.
>
> We define technology inside a context. This context is larger than
> mobile. You may be able to enforce a given approach in the mobile
> industry and that's fine. You may *believe* that the same solution
> could be applied in other contexts, but that only matters if it's
> actually the case. If anything prevents it — technical, economic,
> political — then it's moot. This isn't about browsers — it's about
> everywhere. As it happens, everywhere includes browsers. Yes, that
> means limitations. Those limitations are facts — not "claims". Wishing
> them away won't do anything. Ignoring them will just lead to silo
> technology.
>
> Let me ask a question: what motivated you to support this work in W3C?
> I can only presume that you hoped to see broad support for Web-wide
> technology instead of mobile-only solutions? And further, that that
> would require consensus across multiple industries, not just one?
>
>
> These accommodations may have been interpreted as a sign that a Web
> browser centric design pattern would be adequate (though it will not
> be).
>
>
> Again, this is a very strange claim to make. Interpreted by whom?
> There is nothing browser-centric about the designs we have adopted —
> they simply take browsers into account as a very major component of
> the Web. Again, that involves limitations, and again, we've found
> interesting solutions to make this happen anyway.
>
> If we designed a solution to take battery life into account, would you
> call it mobile-centric? Would someone suggesting that you should "just
> use bigger batteries" or "just deploy induction charging systems
> worldwide" strike you as having found a good solution?
>
>
>
> Thus in the last year we have seen significant erosion of the design
> of the DAP APIs relevant to the original vision of the group (as
> noted above).
>
>
> Again, I am unsure about how you can see that as having been the
> group's original vision when in fact it contradicts the W3C's mission
> of working everywhere.
>
>
> I will reach out to the numerous web runtime (WRT) vendors who will
> be implementing the WAC specs to provide W3C firm evidence of market
> support for the API functionality design and security/privacy concept
> of WAC.
>
>
> That will be useful no matter what, and I thank you in advance for
> making this information available. That being said, I suspect that in
> this instance again when you say "market" you mean "mobile market". Is
> there any chance that you could find similar support across more
> industries?
>
>
> I ask that you also provide the specific feedback that you received
> from vendors (presumably desktop Web browser vendors) which has
> resulted in such a shift in the DAP charter as you propose. Or at
> least, I hope these vendors can provide comments on the DAP list
> which substantiate their positions (including what market segments /
> use cases they are basing those positions on).
>
>
> I do not think that I should share comments made in private but I
> certainly join you in hoping that we receive broad comments here. I
> will however say this:
>
> • The request to define the scope of our work better than it was
> previously has come from several members (in private discussion) who
> have expressed concern that the fuzzy scope meant that they did not
> know what intellectual property would be committed to the group if
> they joined. Irrespective of what one may think of software patents
> and IP, that's how the game is played and I think that this request is
> only reasonable.
>
> • The addition of privacy is actually a bugfix: everyone initially
> thought that it was part of the charter, and was surprised when it
> wasn't. We however proceeded as if it had been there all along.
>
> • Most of the other changes reflect the way in which the group has
> actually operated, and correspond to resolutions made in quorate
> meetings. The fact that external feedback goes in the same direction
> is encouraging, but I can only point out that we did most of these
> changes internally, as a group.
>
>
> There is a wider Web beyond the browser, and our vision for DAP was
> to develop specifications that can serve it.
>
>
> To serve *all* of it, and not just specific vertical interests, yes.
> And we're not serving a Web "beyond the browser", we're serving the
> whole darn Web, warts, history, and all.
>
> --
> Robin Berjon - http://berjon.com/
>
>
>
>
>
>

Received on Thursday, 10 February 2011 02:24:12 UTC