<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?xml-stylesheet href="http://duncan-cragg.org/css/atom.css" type="text/css" ?>
<!-- Copyright (c) 2006 Duncan Cragg -->

<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-gb">
    <id>http://duncan-cragg.org/blog/</id>
    <title>What Not How - Posts tagged 'momo'</title>
    <subtitle>Duncan Cragg on Declarative Architectures</subtitle>
    <author><name>Duncan Cragg</name></author>
    <logo>/favicon.gif</logo>
    <icon>/favicon.ico</icon>
    <rights>All content including photos and images by Duncan Cragg. Copyright (c) Duncan Cragg, your rights preserved: see /CXL.html</rights>
    <generator uri="http://www.djangoproject.com">A Django Production.</generator>
    <link rel="alternate" type="text/html" href="http://duncan-cragg.org/blog/" title="What Not How" />
    <link rel="self" type="application/atom+xml" href="http://duncan-cragg.org/blog/atom/momo/" />

    <updated>2009-02-11T16:20:00Z</updated>


    <entry>
        <id>http://duncan-cragg.org/blog/post/mobile-widgets-arent-mobile-web/</id>
        <title>Mobile Widgets aren&#39;t the Mobile Web</title>
        <published>2009-02-11T16:20:00Z</published>
        
        <updated>2009-02-11T16:20:00Z</updated>
        
        <link rel="alternate" type="text/html" href="http://duncan-cragg.org/blog/post/mobile-widgets-arent-mobile-web/" title="Mobile Widgets aren&#39;t the Mobile Web" />
        
        <category term="architecture" />
        
        <category term="declarative" />
        
        <category term="web2.0" />
        
        <category term="strest" />
        
        <category term="ajax" />
        
        <category term="rest" />
        
        <category term="scalability" />
        
        <category term="momo" />
        
        <category term="microweb" />
        
        <category term="mobile2.0" />
        
        <category term="u-web" />
        
        <summary type="xhtml">
            <div xmlns="http://www.w3.org/1999/xhtml">

<p>

<a href="http://mobilemonday.org.uk/2009/01/february-2nd-event-changing-landscape.html">Mobile Monday London</a>
met last night to discuss the Mobile Web and Widgets. It was an engaging and 
thought-provoking evening.
</p><p>
Your intrepid reporter was there and, in spite of the crashing of his sad, clunky old
Windows Mobile Xperia X1, losing all his notes, he brings you this hot report from
right out of his memory (somewhat steamed up by subsequent socialising, but reclarified by
Google).
</p><p>
After that, I give an explanation of why I believe that Widgets are not the solution
to what Mobile 2.0 needs...
 &#160; ...
</p>

            </div>
        </summary>
        <content type="xhtml" xml:space="preserve">
            <div xmlns="http://www.w3.org/1999/xhtml">

<p>
</p><div class="summary"><p>
<a href="http://mobilemonday.org.uk/2009/01/february-2nd-event-changing-landscape.html">Mobile Monday London</a>
met last night to discuss the Mobile Web and Widgets. It was an engaging and 
thought-provoking evening.
</p><p>
Your intrepid reporter was there and, in spite of the crashing of his sad, clunky old
Windows Mobile Xperia X1, losing all his notes, he brings you this hot report from
right out of his memory (somewhat steamed up by subsequent socialising, but reclarified by
Google).
</p><p>
After that, I give an explanation of why I believe that Widgets are not the solution
to what Mobile 2.0 needs...
</p></div><p>
<b>GSMA ONE</b>
</p><p>
First up was Kevin Smith from Vodafone to tell us about the 
<a href="https://gsma.securespsite.com/access/entry/default.aspx">GSMA ONE Web API</a>
(also <a href="http://oneapi.aepona.com/">via here</a>).
ONE means &#39;Open Network Enablers&#39;. It seems quite similar to the
<a href="http://web21c.bt.com/">Web21C</a>
initiative by BT, led by my good friend
<a href="http://blog.whatfettle.com/">Paul Downey</a>,
but which was unfortunately set aside in favour of
<a href="http://www.ribbit.com">Ribbit</a>.
</p><p>
You can send an SMS, get a user&#39;s location and access billing and connection info. All
through a scary 
<a href="http://duncan-cragg.org/blog/post/strest-service-trampled-rest-will-break-web-20/">STREST</a>
interface. 
</p><p>
Scary because it looks like you can 
<a href="http://www.betavine.net/bvportal/web/guest/projects/resources/api/gsma_api">send a text using a GET</a>... 
The documentation
<a href="http://oneapi.aepona.com/content/gsma/tutorials/GSMA_Access_API_Messaging_REST_Tutorial.pdf">here</a> [PDF]
does suggest using POST, but even so, the design fundamentally wants Resource-Orientation 
in place of Service Orientation:
</p><p>
The message appears to be tacked on to the URL as an argument.  There are references to
&#39;soapUI&#39;, endpoints, etc. An SMS message doesn&#39;t appear to have its own URL, just an
internal message ID. There are &#39;exceptions thrown&#39;, all with a 400 code, even for
internal platform and integration faults.  And so-on - in classic
<a href="http://duncan-cragg.org/blog/post/strest-service-trampled-rest-will-break-web-20/">STREST</a>
style! 
</p><p>
Still, nothing that can&#39;t be fixed with a little help from a REST dude, or a read of 
<a href="http://oreilly.com/catalog/9780596529260/">&quot;RESTful Web Services&quot;</a>.
</p><p>&#160;</p><p>
<b>OMTP BONDI and Ikivo</b>
</p><p>
Next, Nick Allot told us all about
<a href="http://bondi.omtp.org/">OMTP BONDI</a>,
which is an attempt to ameliorate fragmentation in the mobile Web and widget space - the
one which allows access to parts of the phone not normally reached in a browser: PIM,
SMS, camera, GPS, etc.
</p><p>
Their big thing is security: take widgets out of the safety of the browser and give them
access to the phone via APIs, and you have a potential security nightmare. 
</p><p>
Seems BONDI will let you do most Mobile 2.0 native-like 
<a href="http://bondi.omtp.org/widget-gallery/">applets</a>, such as LBS, photo-sharing, etc.
There&#39;s a reference implementation for sad, clunky old Windows Mobile, and both 
<a href="http://www.gomonews.com/bondi-initiative-from-omtp-to-defragment-mobile-internet/">Opera and LiMo are jumping aboard</a>,
too.
</p><p>
BONDI aims to be W3C compatible where possible. Not HTML5, mind, but rather a works-now,
fit-for-purpose solution to the fragmentation problem, that includes widgets and may
later converge with HTML5. There&#39;s an 
<a href="http://wapreview.com/blog/?p=1184">excellent discussion</a>
about this on WAP Review.
</p><p>
This was followed by a talk by Samuel Sweet from 
<a href="http://www.ikivo.com/">Ikivo</a>.
It seems that, starting with their successful
<a href="http://www.gsmarena.com/samsung_release_the_t*omnia_in_korea__omnia_but_on_steroids_-news-656.php">Samsung T*Omnia</a>
widget interface, Ikivo have been overcome with standards love, and are going BONDI as
well as W3C compliant, especially with SVG as a rendering technology.
</p><p>&#160;</p><p>
<b>Firefox for Mobile</b>
</p><p>
Christian Sejersen of Mozilla gave a good intro to what is currently called
<a href="http://images.google.com/images?q=fennec">Fennec</a> - Alpha 2,
but will soon be renamed the more grown-up &#39;Firefox&#39;. It&#39;s got the same code in it after
all: and APIs such as camera and location that get added to the common codebase
will be accessible via both mobile and desktop.
</p><p>
<a href="http://vimeo.com/2577978">Looks very swishy</a>
and touchy and in sync with the times. Available now on Maemo (and 
<a href="http://moblin.org/category/tags/fennec">Moblin</a>)
and soon on sad, clunky old Windows Mobile. Then later this year on Symbian.  Codebase
is C, so no Java or Javascript phones supported, of course. Or closed walled-garden
proprietary locked-down phones like, um, the iPhone. It seems that the add-on community
is already fixing up their plugins for this mobile version without even being prompted.
No news on the <a href="http://labs.mozilla.com/2007/10/prism/">Prism</a>
widget-alike system, to compete with BONDI or Opera. It&#39;s &quot;still in the labs&quot;...
</p><p>&#160;</p><p>
<b>Panel</b>
</p><p>
Then the panel session started, with the best questions from the excellent host,
<a href="http://www.torgo.com/blog/">Dan Appelquist</a> of Vodafone,
and some good ones from the audience.
</p><p>
There was much elaboration and clarification on the presentations (thus included above
instead), and an interesting conversation around monetisation: how do widgets make
money? Three suggestions: adverts, selling widgets on an app(let) store and
micro-payments. Graham Thomas of T-Mobile appeared to be happy just to get more Internet
traffic for now..
</p><p>
There was also confirmation from Graham that Web&#39;n&#39;Walk 4.0 will major on widgets, but
he didn&#39;t say what flavour. More hot journalism uncovers
<a href="http://www.smartphoneshow.com/files/_15.30_jon_tetzchner_innovate_collaborate_accelerate.pdf">this confirmation</a>
[PDF] (page 29) that it&#39;s still going to be tied in with Opera.
</p><p>
The outstanding revelation of the evening (sorry Ikivo!) came when someone told us that
the Palm Pre&#39;s widget system is not only proprietary, but <i>uses tables for layout</i>!
The horror! Lots of tutting and W3C-like smugness around the room.
</p><p>&#160;</p><p>
<b>Following Open W3C Standards can still break the Web</b>
</p><p>
The goal of all this standard widget aspiration, apart from the obvious motivation of
being able to compete with the iPhone, is to allow everyone to write widgets, and for
those widgets to work on all our phones.
</p><p>
However, <i>just because everyone does what the W3C thinks they should do doesn&#39;t mean you
automatically get interoperability</i>.  Most importantly, doing what the W3C wants
doesn&#39;t mean you won&#39;t break the Web!
</p><p>
The W3C, don&#39;t forget, also brings you &#39;Web&#39; Services - those mis-named standards
responsible for much Web-breaking, including inspiring a whole generation of
Web-breakers with their 
<a href="http://duncan-cragg.org/blog/post/strest-service-trampled-rest-will-break-web-20/">STREST</a>
interfaces.
</p><p>
Interoperability on the Web is about state transfer, content types, URLs, hypertext. No
amount of API and widget standardisation will give classic Web interoperability as long
as they ignore these Web basics.
</p><p>
A widget is an applet is an application. It&#39;s a closed structure whose data interoperability
has to be hard coded each time, and whose imperative Javascript naturally wants to
make function calls back on the server - probably through HTTP.
</p><p>
And you run either this application or that, each having its own way of pushing or
pulling data around, or even the same data presented in much the same way all over again.
</p><p>
In the Web you run one browser application and everything is mashed within - data interoperability.
</p><p>&#160;</p><p>
<b>The U-Web gives us the best of both worlds</b>
</p><p>
Admittedly, the basic Web isn&#39;t good enough by itself when seeking an architecture for
Mobile 2.0&#39;s essential personalisation, interactivity and usability.
</p><p>
But that doesn&#39;t mean that we should throw away the Web&#39;s hard-won advantages of
interoperability and scalability, that we perhaps take too much for granted.
</p><p>
Enter the <a href="http://the-u-web.org">U-Web</a>!  The U-Web &quot;puts the Web back into Web 2.0 and
Mobile 2.0&quot;. 
</p><p>
It takes the best of the Web&#39;s one-way static document publishing model, and extends it
to a two-way dynamic data exchange model, while keeping the interoperability and scalability
of the Web.
</p><p>
Instead of working on widget standards that break the Web, let&#39;s standardise a fully
Web-compatible Mobile 2.0 architecture that delivers the same rich, personal
functionality, but adds back the seamless mashability of ever-changing people and their
ever-changing stuff. Oh, and promises scalability and rapid, easy development.
</p><p>
I&#39;ve kicked off the project with the <a href="http://the-u-web.org">U-Web</a> proposal - perhaps
you&#39;d like to jump in and help? Email me (see left bar) or leave a comment.
</p><p>

</p>

            </div>
        </content>
    </entry>
    
</feed>

