Summary of GNOME Mobile summit in Austin

Hi all,

Here's a report of the GNOME Mobile summit we held in Austin a couple of
weeks ago - sorry for the delay in sending it on.

I've slightly sanitised some stuff, because a couple of details were
either not cleared by the concerned parties for public release (and they
weren't there to defend themselves), or because the concerned party
asked to keep it quiet for a while.

Do people think it would be useful to have a post-summit release saying
we had a successful summit and outlining some of the actions coming out
of the meeting? I feel like it would be non-news, and it's probably best
to wait until (say) the first beta of the GNOME Mobile release set in a
few weeks to announce something concrete.


GNOME Mobile summit report

Many thanks to Paul Cooper and Rob Taylor for getting me started on this
and sending me their notes of the sessions, it was just what I needed to
get over my procrastination.

First an overall summary: The day split into four distinct parts, and
many interesting conversations happened between these parts over coffee,
cake and cigarettes. There was also cake in the meeting room on a couple
of occasions.

The meeting did suffer a little from having several competing sessions
running at the same time. Throughout Thursday, there were parallel
sessions for Linux mobile/embedded, power management and desktop
architects going on. Nevertheless, we managed to have over 20 people
most of the day, and about 35 people made an appearance during the day.

Agenda outline

- Overall strategy of the project
   - Communication
   - Members, partners, consumers
   - Branding, positioning (who is our audience? What is our value to them?)

 - Code to upstream
   - general outcome: Needs to be done on a case by case basis
   - there isn't necessarily a resource issue, other than time.

In particular: DBus ports of EDS, GConf could be upstreamed soon. There
are some patches in Hiker, and OH patches to the file chooser, which
could be upstreamed too.

 - Defining the release set for the platform and fixing mid-term goals
for the project

 - Listing technology gaps in the platform
   - identifying 3 or 4 which are obtainable within the community
   - this could be the basis of a roadmap for the platform over coming


* Who is our audience?

Application developers, and hardware/mobile platform vendors

Application developers: you can write an application against GNOME
Mobile and have it be useful (implies going high enough up the stack for
this to be true).

Mobile platform & hardware vendors: There is a growing meme (which is
profiting Android) that mobile Linux is fragmented. Branding GNOME
Mobile as a useful LCD among platforms like Maemo, Hiker, Moblin, LiMo,
GPE, ALP, Poky/Sato, Ubuntu Mobile ... allows each of these platforms to
react to the fragmentation story by pointing to shared technology.
(Question: how much of the GNOME Mobile platform should be used before a
platform can be called GNOME Mobile? Is GNOME Mobile a useful platform
to target?)

* Certification program:

Ideas to come out: "participating in the GNOME Mobile workgroup" as
being sufficient for a badge. Requiring at least GTK+. Identifying some
reasonable subset of technologies that "everyone" uses.

Badging: Approach platforms considered GNOME Mobile and sell the idea of
the GNOME Mobile foot on device packaging to them. Jeff has done some
work on this already (we should get the GNOME Mobile artwork sent to the
mobile list).

"Proper" certification: It would be possible to have a GNOME Mobile LSB
test-suite which would be used to test both platform compliance and
application compliance with the GNOME Mobile platform. It's a long term
goal, but one to bear in mind.

* Project goal/mantra/vision: "The standard foundation for open-source
based mobile devices" (suggestion from Lefty)

* Project targets:

Aiming for ISVs: We need a downloadable demo to make the project real,
otherwise it doesn't exist. We need to have a cost & time to market
story (building on GNOME Mobile can reduce your time to market for a
device, and reduce your R&D costs - have some examples to hand - and if
we can't tell this story, what is our selling point?).

GNOME Mobile is
 1. A platform
 2. A community

Need to collect stories - reference platforms & industry consortia using
the platform, devices based on GNOME Mobile, GNOME Mobile applications,
"downloadable Bling!")

* GNOME Mobile HIG?

Dan Kohn suggests that it would be useful for ISVs to have interface
guidelines (à la iPhone) for applications. Somme dissention: the mix of
platforms, input methods & form factors would make it difficult to
achieve a lowest common denominator, and N different HIGs would be a
maintenance nightmare.

That said, there was some support for the idea of updating the current
HIG to include some basic mobile concerns, have a general "mobile
application" section, with form-factor/usecase specific appendices (eg.
nettop/laptop, mid, smartphone, dumbphone) (I don't really understand
what all of these are, I just took notes).

* Tangents:

In any discussion like this, you get tangents. Here's a sample:

 - Is Maemo dropping GNOME for QT? There's a perception of a change of
 - Clutter is cool. Look, e flips the video!
 - Android is the Devil! The Devil, I say!

* Website:

The website is now out of date. It needs updates, with:
 - A list of participants in GNOME Mobile
 - A collection of sample platforms, apps

We should gather a list of possible participants, projects, consumers of
the platform.

Upstreaming code

This discussion ended up being short.

* EDS DBus: Ross plans on doing it, just doesn't have the time. Q: Is it
a resource issue? Probably not - no-one but Ross is really equipped to
make it happen.

* OH File chooser patches: submission planned

* Hiker patches: About 10K lines of patches to GNOME components in the
Hiker platform, their technical guy has been working on pushing those

* Maemo: Tommi has maintained a good page of all the outstanding
patches, all of the useful stuff has been submitted upstream.

No-one else patches GTK+ or the rest of the platform  ;)

Release set, mid-term goals

Need a downloadable VM-based solution people can code to.

Ross can get a Poky image up & going, and has just checked in a jhbuild
module set. The Poky VM can be one of many - other platforms are welcome
to provide sample VMs.

Release set:

The original release set at has GnomeVFS,
should be replaced with gvfs.

Perhaps X could be a soft requirement, some interest in DirectFB.

SQLite was also suggested for the platform.

Bits that goe marked as the corest of core components: BlueZ, GStreamer,
Matchbox, Gconf, GTK+, DBus, glib, and either X or DirectFB.

The list of candidate technologies we came up with was:
Java ME (parts)
Hiker (parts)
Hildon (parts)

General agreement that HAL was good for the platform. Other candidates
that got good support were PulseAudio, GUPnP, TinyMail, GeoClue.
Probably for consideration in 2.26?

Ross's plan is to be conservative for the first release, and just make
sure it happens with the core components on the gnome-mobile site.

In terms of browsers, there was general concensus that we're too low on
the stack to force/choose a browser component, WebKit and Mozilla Fennec
will both be options.

Phoneme also came up.

Both Hiker and Hildon may have separable components useful for the
platform - candidates should be identified and evaluated on a case by
case basis.

Technology gaps

We identified a bunch of technology gaps - mostly brainstorming - and
identified some of them that are at least partially addressed by current
candidate technologies. We marked a few for particular short-term attention.

* Telephony framework & plug-ins
* Presence/location
* Synchronization (sp)
* T9/predictive text input
* Handwriting recognition.
* Voice commands/recognition/text to speech
* Power management
* Policy management
* Security
* App management
* Connection management
* Input framework
* Notification/alarm/alert
* Camera/video

Some of these are partially addressed by existing libraries:
G(PE)2, Telephathy: Telephony framework
Geoclue, Gypsy: Presence/location
OHM: Power & policy mgmt
Hiker, NM, Moblin: Security, app mgmt, connection mgmlt, notifications

Some of them (T9) are patent minefields.

In the end, the decisions were to attack those with partial solutions,
and also to push one major feature need: synchronisation and one other
major feature: DLNA.

Thet's as I noted it - if there are any additions, omissions,
corrections, please feel free.

Courtesy of Rob Taylor, here's a list of useful links related to things

Dave Neary
dneary free fr
Tel: +33 9 51 13 46 45
Cell: +33 6 77 01 92 13

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]