Re: Question from IETF's Interenet Architecture Board (IAB) web apps, native apps, web-based apps

Hi Robin, 

thanks a lot for your review of the "post standardization" document. I agree with all your input and will update the document accordingly. Good feedback!

Regarding the main part of my request to the TAG: 

> 
>> There are two fundamental ways to write applications (as they have always been), namely 
>> 
>> 1) Native applications focused on the target operating system
>> 2) Web applications that run in the browser regardless of the operating system
> 
> It's a bit more complicated than that actually, and there is strong dissent about whether this distinction is actually relevant or if it should only be used as a shortcut that is highly dependent on the state of play at this very moment (but will likely be obsolete as a concept relatively soon).

Interesting view. Any references to write-ups or article that I could reference? 

> 
> To take examples that don't clearly fit above:
> 
> • We used to have applications built with Java, that target the VM rather than the OS. In which box do these fit? The same question applies to using Perl/Ruby/Python/Tcl/JS/whatever with a common toolkit such as Tk or WxWindows.
> 
> • If all the application-level layers of your operating system are Web-based (B2G, Tizen, webOS) or a substantial part of them (Win8), when you build an application is it Web or native?
> 
> Is it a Web application only if it runs in the browser? Is it okay if it saves an icon to your desktop that launches it in a chromeless browser? What if it runs in a browser but as proprietary content interpreted through a plugin?
> 
> By and large, I don't think that that distinction is useful beyond discussions clearly rooted in the current situation and not meant to be future-looking.

Good points. 

I believe there are some main differences between the mentioned cases and please correct me if you see it differently.  

While there is the possibility to download code in many systems there is the question how these updates are accomplished and how the security model works. There are also differences in what it means from a standardization point of view. 

When we did the GEOPRIV work we say it as a protocol design exercise (where the communication protocol could be everything from SIP, XMPP, to HTTP -- even though there was an excessive focus on SIP based on the use cases that some of us had for he emergency services environment). While we provided lots of flexibility in the protocol there are certainly limits (if you for example look at the way we had to design the location filters, see http://tools.ietf.org/html/rfc6447). Of course one could now write a Java applet and download it via the browser and then have the application do whatever it is supposed to do. The user would have to accept the software installation. You guys had taken a very different approach in the W3C with the focus on the JavaScript geolocation API. Of course there will be a permission dialog as well when the user's location is distributed but otherwise the code that gets send to the browser may change at any time (whenever I load a new page) and there may even be code folded in from other sites as well. 

Wouldn't you say there are differences in the way how JavaScript works and the way how Java/Python/etc. works even though they all may well be executed within a virtual machine?

I understand that some applications do run in a browser like environment even if the different user interface (different chrome) makes the user believe it isn't. 

> 
>> In addition to these two approaches there is also a third one in the mobile space where you package a Web application so that it looks like a native application. 
> 
> That is known as a hybrid application. The same sort of issues apply as discussed in the previous section.
> 
>> From year 2000 onwards we had seen a lot of shift from native applications to Web applications. There may be many reasons for that but I believe the main advantages were: (...)
>> * The security of downloadable native applications was just horrible. Web pages with JavaScript in there offered much better properties in that regard. 
> 
> Actually I don't think that that was a driving factor apart from maybe a tiny geek elite. Today's app stores are extremely successful despite offering pretty laughable security overall.

> 
>> Over the last few years there was a lot of development in the operating system section (on the mobile side) and the application eco-system has changed quite a bit as well. The development had impact from a security and an economic point of view. There seems to be some excitement for application stores that aims to provide additional revenue to developers and at the same time they serve as a gateway function for distributing applications. 
>> 
>> While there is great progress with the work you guys are doing in the W3C on the Web platform environment (as would call it), I would mostly say in the area of JavaScript APIs, there is still the question of where the development will be going. 
> 
> I'm still rather vague as to where the exact question is in that statement, are you looking for something similar to http://berjon.com/blog/2011/07/there-is-still-a-frontier.html ? The content in there is pretty old and it doesn't cover the progress we've made since thinking about privacy and security, improved thinking on Web Intents and what it means for the Web, or the more recent discussions around cars programmed with Web technology (which are moving fast, figuratively). Or TV. It also doesn't discuss issues with the security of the home network once exposed to the Web, which is a very interesting space (where by "interesting" I mean that it's a complete mess and we'll need a solution).

Thanks for the link; will have a look at it. 

Let me try to explain you again what we tried to accomplish with the document. The post standardization draft tries to figure out what the implications for standardization (particularly in the IETF) are. 

In general, we are making the observation that the client-to-server interaction is not necessarily standardized in the way we did the work (e.g., for email or SIP) in the past. We had presentations about this at the Prague IETF meeting at the IAB technical plenary in case of SIP. Despite all the standardization efforts in SIP the level of interoperability is rather limited. It also turns out that many do not care about the interoperability on the client-to-server leg and instead providers implement whatever extensions they want to serve their customers best. The smart app developments go into that direction as well. An app developer may want to develop their software in such a way that it interacts nicely with their own servers and, only if really necessary, have interaction with other sites -- typically in the backend. 

Then, we argue that the developments around JavaScript are special since JavaScript is not just yet another programming language. When we wrote the post standardization document a little while ago there were various limitations with the available JavaScript APIs that do not exist today anymore. In some sense the developments in the last year support our arguments in the document.   

For example, take the Web CryptoAPI: When this work is finished you may be able to implement any authentication and key exchange protocol in JavaScript based on the API primitives that you guys are developing in that group. We are currently having these discussions in context of HTTP 2.0 whether new authentication mechanisms should be standardized and what. There are proposals on the table that provide specific features. Now, you could argue that there is no point in standardizing one specific protocol solution when you can easily write whatever mechanism you have in JavaScript with the CryptoAPI extension. (Assuming that you do not care too much about the layer.)

This is what I call impact for standardization. 

In order to explain this impact our story needs to be sound and if we argue that lot of this development is driven by JavaScript but the entire Web development efforts get overrun by non-JavaScript based native mobile phone alike application developments then our awareness raising looks a bit foolish.  

Some of my IAB colleagues go as far as saying that there is little value in standardization at the application layer based on what they see happening in the smart phone app development space. 

Ciao
Hannes

> 
> Do those notes help? Or were you looking for something else?
> 
> -- 
> Robin Berjon - http://berjon.com/ - @robinberjon
>

Received on Thursday, 21 June 2012 10:52:50 UTC