Summer of Code 2008

From Openmoko

Jump to: navigation, search

Contents

Introduction

The Summer of Code is a student funding program from Google. It funds students to write FOSS code during the summer. You can find out more about the program at http://code.google.com/soc/. (For accepted projects, see http://code.google.com/soc/2008/openmoko/about.html.)

Also, you might want to check into last year's run at Summer of Code 2007 .

Timeline

  • March 13-17: Google program administrators review organization applications.
  • March 17: List of accepted mentoring organizations published on code.google.com/soc/ (~12 noon PDT/19:00 UTC).
  • Interim Period: Would-be student participants discuss application ideas with mentoring organizations.
  • March 24: Student application period opens (~12 noon PDT/19:00 UTC).
  • March 31: Student application deadline 5:00 PM PDT/00:00 UTC April 1, 2008.
  • April 07 (update): Student application deadline extended to this date!
  • April 21: Accepted student proposals announced on the Google Summer of Code home page.

Students welcome!

If you're a student who came here to check out the projects Openmoko is offering to host you may not be familiar with what we're doing here. To change that it suffices to say that we're out to create the world's first completely open mobile phone software stack. With Openmoko we want people to be able to do with their phones whatever they want to do instead of being limited by what the vendor allows. Here you can find Sean's great introduction which tells you how it all came about and what our plans are in detail.

The skill requirements for the projects differ, though we want to make you aware of the fact that the framework is still undergoing major construction. That means that you shouldn't be afraid of getting your hands dirty and help out with framework code or adapting to new APIs as they grow and mature.

Accepted Ideas

Implementation of a Openmoko remote controller

Nowadays the regular mouse and keyboard aren't the unique form of input with a computer, the technology evolves and some new gadgets appeared to provide to users news forms of interaction with computers. The mobile phone can be a new form of interaction with a computer, because nowadays this device are evolves a lot and they have some new technology's like Bluetooth and Wifi, this can provide a new and cheap way of interaction with computers, because the mobile phones are nowadays a very common device in our world. The Openmoko powered mobile phones, are a much more than regular phones, are mini-computers do the amazing technology inside them, this can be a great advantage. My proposal consist in the development of a Openmoko application that can interact with a computer like a remote controller, using the Bluetooth HID profile.

More info at ReMoko

IM/VoIP using telepathy

Telepathy is a D-Bus framework for unifying real time communication. Having a user interface for telepathy would give Openmoko instant access to various IM protocols. For example the Chat (and voice) communication via link-local and zeroconf of the Ad hoc communication via Bluetooth proposal above would be instantly solved by having telepathy-salut on the device.

Telepathy can also be used for VoIP. Currently it's able to do both SIP and Google talk. Having support for telepathy-based VoIP would be great.

And finally for extra bonus points: having a simple Telepathy CM for sending SMS and doing GSM calls would be a way to standardize on one interface for all voice/text communication. However, this could probably be a SoC project on its own and would need evaluation to make sure it aligns with Openmoko's architecture.

http://telepathy.freedesktop.org/wiki/

Accelerometer-based Gestures

Home of Gestures. Read more on how the project is going here. Accelerometer-based gestures will allow isolated and continuous gesture recognition through a shared library. A catalogue of predefined gestures (up-side-down, shaking, flipping, twisting, etc.) will be delivered; you will also be able to create your own gestures (only for advanced users: you'll need some pattern and hidden Markov model knowledge to make your own gestures). An application with user interface will enable training on existing gestures.

More info at Gestures

Speech Recognition in Openmoko

A speech recognition program for the Openmoko would be a good tool to access the various features of the phone through users voice input. The tool may be trained for certain period of time and could be used to perform the desired user task.

Synopsis: The project will aim to build an application which will perform speech recognition or in simpler words, it will recognize a spoken word by comparing it with a small dictionary of words(normally 5 or 10). This will be done by implementing Hidden Markov Model for training and recognizing a word. The application mainly consists of four steps: 1) Feature analysis 2) Unit Matching 3) Training 4) Recognition The user will be able to store his/her own words using the training procedure.

A detailed description of this project and related material can be found at here. The GSoC project abstract can be found here. the current status and progress report of this project can be seen through here.

Openmoko Mail

Communication-ability is one of the most important things for a mobile device. For a Wi-Fi, GPRS device as the market version of 'Neo' will be, a multifunctional e-mail client is more than a need.

Existing solutions

Currently I am aware of only one implementation of mail client for Openmoko based on tinymail. It currently has working email reading and writing for multiple accounts, including basic attachment support, replying and forwarding as inline or attachment.

Proposal

As part of the Google Summer of Code 2008 program, I plan to improve the usability, functionablity and flexability of the already Existing E-Mail client (described above). To do that, I plan to:

  • Update the Mail client for the latest version of libtinymail.
  • Add a support for Contacts
  • Add a support for file browsing for the attachments
  • Add a support for HTML Mails
  • Add a GPG support for the Mail client
  • Implement a Password saving option
  • Add SMS support
  • Implement EFL-compatible interfaces to libtinymail-ui

So the Openmoko Mail will suit all of the basic needs for Buissness and Normal clients of Openmoko.

More info at Openmoko Mail

Flexible Answering Machine

Regular answering machines are located in your flat or at your provider. But in a mobile world it might to have one device in your pocket which controls all of them. This has the advantage of leave current messages for the caller instead of something default nonesense. This message might be a SMS or prerecocreded message with information about where and when you are available. It is also useful to have access to different machines at the same time (e.g. company, home and mobile) to answer all calls as soon as possible.

Targeted SELinux Policy For Openmoko

Openmoko devices run all processes as root. This leaves an attacker many opportunities for privilege escalation. This project will develop a "targeted" SELinux policy for Openmoko with a focus on system daemons. A simplified "targeted" SELinux policy is beneficial because it significantly improves overall security on Openmoko devices.

SMS middleware

Hit here for more information project status, ideas and wishes.

My proposal is to write a middleware that catches all incoming/outgoing SMS messages and process it according to user activated features. By default, this software should be off or have all features disabled, because of CPU usage and delay of incoming SMS. Here are features I would like to implement:

  1. Users should have possibility to schedule SMS to be sent at a certain time and/or date – this needs no explanation.
  2. Plugin Service – very important!
    Users should be able to remotely control some basic functionalities of their phones.
    A user has a list of input fields where he can add new regex and assign action to them. If incoming SMS matches any of regex, than a specified action is invoked. This feature works immediately after new SMS has arrived. It looks like “filters” in GMail.
    This feature should be a plugin service, so anyone could later write an action that he want to assign to regex. I am planning to implement:
    • “theft-mode” activation (whatever it means)
    • with secret “codeword” sent as SMS to your mobile, you can get the GPS coordinates from a stolen device (see #6 below)
  3. Confirmations handling
    User can turn on filtering of “status” messages – they should NOT go into incoming SMS list but only change an icon of SMS from “sent” to “sent and ack” – this is just one pretty image.
  4. Anti-spam filters – very important!
    User can enter regex on his own or click a button to update list of filters (like AdBlock Filters in Firefox) from a special server (because of GSoC time limit - there will be only mock-up for server – just an imitation). If there is more time - I can also implement a server where users can contribute their regex, via web, so anyone can download them.
    All SMS marked as “spam” will be moved to a separate list “SPAM”. “SPAM” list works the same way like INCOMING with exception that mobile doesn't notify about new SPAM messages (they are silent) in a way it would happen for “legal” SMS (sound, vibrations, back light).
  5. Full text searching inside inbox and/or outbox
  6. Auto-substitution of outgoing SMS. This should be a simple replacing of special magic variables inside tags. Example SMS: “No mom, of course I am at school {{position}}”, “You are wrong, actual time is {{time}}”, “Your GSM provider sucks, I am using only {{provider}}”.

Open Device Daemon complying with freesmartphone.org specs

Synopsis

To increase interoperability between different open platforms in the smartphone market, freesmartphone.org was created, providing standard specifications for device and phone daemons. My project for this summer will help complete the specifications of odeviced, the device daemon for fs.o and implement the same in the Openmoko FreeRunner/Neo1973, replacing the current neod. This along with ophoned could make Openmoko FreeRunner the first smartphone complying with fs.o specifications.

Deliverables

  1. Complete the odeviced specifications for freesmartphone.org (fs.o).
  2. Create a preliminary framework of odeviced based on pulseaudio on the Neo1973/FreeRunner.
  3. Create plugins that are of highest priority like power management and keypad/button management.

Long term Goals

Long term goals include,

  1. Create plugins for other devices that run Openmoko.
  2. Support for plugins written in higher level languages like python.
  3. A GUI for managing odeviced plugins.

PIM storage for the mobile world

The FreeRunner smartphone manufactured by Openmoko, Inc. was initially trying to re-use as many parts from the desktop world as possible. However as it turned out, the chosen PIM infrastructure (Evolution Data Server) isn't quite cutting it: it's nice on a desktop but not flexible enough to perform the kind of tasks we'd expect from a next-gen smartphone. Replacing/extending it *is* a big task however, and there always were other areas that required the staff's attention more urgently.

With the middleware initiative started and time pressing more than ever, I would like to devote myself to this task using the resources provided by the Summer of Code. Fellow developers are still held back by the lack of an officially accepted and supported API, so this is where I would start. After that I'd check how feasible it is to extend eds-dbus or whether something new needs to be created. In the latter case I'd also check if we can build on partial solutions like camel or akonadi. Once this has been determined I'd start work on either the eds-dbus extension or the design and implementation of a PIM service/daemon. If time permits I'd also begin doing integration work into other daemons/GUI applications, though my focus would lie on the PIM service itself.

Rejected Ideas

Plan 9 Port

Port Plan 9 to Openmoko and write some documentation on how to use it in this special context. There are mentors available for this project in Plan 9 if one is not available from Openmoko.

Processing on Openmoko

Evaluate the feasibility of having Processing running on Openmoko and the difficulty of integrating it into the Openmoko environment as seamless as possible - that means interfacing to the daemons using D-Bus, for example. If doing this proves feasible, make Processing run on our hardware platform and write some documentation on how to use it, maybe with a simple demo application.

Sip / Video client in Openmoko

It will be nice to have in Openmoko a client to register to a sip server to make call using an external provider, and to transmit/receive video using open standard. It can be usefull for who has wireless network at home. It will be nice to have also an Openmoko ufficial sip server for testing propouse and to free speack in Openmoko comunity. The client must to support multi account. The video source can be a supported webcam.

Create a set of standard widgets using EFL

The Openmoko platform obviously wishes to have a look'n'feel that is similar across all future applications. To achieve that, a set of standard widgets optimized for a SmartPhone needs to be determined, designed, implemented and documented. These Widgets should be completely self-contained and equipped with proper signal/slot handling, so that you can use them as Edje parts.

Ambient Noise Detection

Wishlist:Software:Ambient_Noise_Detection could be implemented as a D-Bus-utilizing daemon that controls/signals the other daemons according to environmental sound levels.

Centralized event handling infrastructure

In order to allow situation-aware phone behaviors (e.g. "don't ring if GPS says we're in the meeting room", "turn on Bluetooth when I'm near my car") it makes sense to have a centralized filtering mechanism where events pass through and get either forwarded, rejected or maybe altered. Designing, implementing and documenting such a filter using D-Bus IPC would be the core task of this project.

The author should evaluate the requirements of the event protocol, analyze use cases, design the protocol and implement it. If time permits, it would be great to integrate the centralized event signalling infrastructure into other daemons as well - e.g. libgsmd/pygsmd/pygpsd.

Ad hoc communication via Bluetooth/WLAN

We want to be able to chat, send files, have internet connectivity, exchange contacts, ...

The following issues need to be addressed:

  1. Make BT/WLAN discoverable
  2. Ad hoc pand connection
  3. IP connectivity via zeroconf
  4. Chat (and voice) communication via link-local and zeroconf
  5. Interoperatibility with the other daemons to perform said tasks
  6. GUI controls to access settings/perform actions

Cooperative Differential GPS

  • DGPS is a local minute by minute 'ionospheric weather' for your region, as well as reports of the small errors in the satellite orbits and clocks.
  • This can generate positions accurate to dozens of centimeters, compared to (probably) 2-3m without.
  • This needs more information than simply the computed position to work on, as the corrections need to be performed on a per-satellite basis, before generating the position.
  • The per-satellite errors can be derived from a suitable static GPS (For example a Neo1973 on charge) and then uploaded to central server(s) to generate a global DGPS map of errors, allowing any CDGPS reciever to connect to the server, and download a few hundred bytes of correction for their region.

This provides an excellent companion to AGPS. With one connection to the server, a CDGPS reciever can download a several K packet of all the information needed to get a position within 10cm in the first couple of seconds, even if it's been off for weeks.

Normal operation would be under a few hundred bytes every time an accurate position is desired.

Hardware:AGPS#Q: What is DGPS, can DGPS and A-GPS work together.

http://lists.openmoko.org/pipermail/community/2007-March/004086.html

http://lists.openmoko.org/pipermail/community/2007-March/004093.html

http://lists.openmoko.org/pipermail/community/2007-March/004127.html

http://lists.openmoko.org/pipermail/community/2007-March/004111.html

http://lists.openmoko.org/pipermail/community/2007-March/004123.html

Support/documentation for building Applications in Python/Ruby

Maemo has Python bindings for building native Hildon UI applications in Python. This project would create similar support in Openmoko for building 'native' applications with full UIs in Python and/or Ruby and proper documentation to make the transition as smooth as possible. Doing so would allow additional developers to quickly prototype and build new applications for the Openmoko platform.

Support should focus on the EFL framework, D-Bus interfaces and integrate up-to-date work of the middleware folks, where appropriate (they don't bite, so staying in close touch is recommended). Examples of areas that should be covered: creating application windows, UI widgets/layouts, hardware interfaces, network connectivity, documentation on how to port/integrate existing modules/libraries to the platform and so on.

IM/VoIP using Retroshare

http://retroshare.sf.net is a serverless Instant Messenger with c++/Qt, which could be brought to openmoko with GTK gui or a resized Qt gui.

Port Openmoko to the Motorola EZX mobile phones

This proposal covers three major steps.

  • 1. Make Openmoko suited for QVGA devices.
  • 2. Port EZX mux driver to the new TS07.10 infrastructure and adjust libgsmd/pygsmd.
  • 3. Optimize Openmoko code on running on 48MB ram devices.

Moblog client

Moblog would be a next generation feature. Here at Openmoko we are to build the efficient moblog client software. The software should be able to fetch information from the moblog as well as Submit new content. A mobile user can blog from his mobile, he can share images, ringtones, audio and video. The software needs to keep in mind the memory shortage, screen size and bandwidth of such a limited device. The software could be developed in javame to also support android and other platforms. To make it more mobile friendly it should be customizable for different mobiles.

Podcast/newscast recording/cutting tool

This GUI tool would let the user record a podcast, do simple cutting/takes on the run and send it back to the studio or right to your blog. Of course it should also let the user attach a small message with the blog submission so it can create a meaningful new blog post.

Audio/video player extensions for the feedreader

The feed reader should ideally be able to play podcasts straight from the source so it would be nice to have this feature integrated. The gstreamer infrastructure should be used for this task.

Pasalo, social networking application

Problem: Transferring information in cellphone devices is many times a difficult task that requires multiple steps, making regular transfers of information a pain.

MythTV Advanced Remote Control

Bluetooth/WLAN-based remote control for MythTV, which for television channels, would show a view like a mini-channel guide (complete with preview, if tuner is available). For mythvideo, it would show all of the details and cover art. Neo could act like a MythTV slave, where television shows could be shown on the Neo as well.

http://gmyth.sourceforge.net/wiki/index.php/Main_Page seems to handle all that, but lacks a nice (moko) GUI

Input Widget system & example widgets

Openmoko needs a widget system that makes it easy for developers to make their own input methods and for users to add them to their installation. This needs to be flexible enough to support every possible way of text input one can think of but at the same time has to work with everything requiring text input. A basic set of input widgets (optionally predictive QWERTY keyboard, multitap keyboard, some sort of slide input) should be included. Some discussion about input methods can be found in the mailing list archives, for example here.

Idea: To create a push/pull model for sharing files/data via wifi and bluetooth with trusted individuals, combined with a trusted key security model based on social networking model, with the intention of creating social communities that transcend the virtual arena.

More ideas on Wishlist

A list of existing code ideas can be found on the Openmoko Wishlist. Some of these may make good candidates for the SoC.

Mentoring tips

A guide for how to be a good mentor can be found here.

Current projects

Openmoko Remote Controller

Student
Valério Valério
Mentor
Daniel Willmann
Project page
http://wiki.openmoko.org/wiki/Openmoko_Bluetooth_remote_controller (ideas and wishes)
ReMoko

SMS Middleware

Student
Patryk Szymczak
Mentor
Michael Lauer
Project page
http://wiki.openmoko.org/wiki/Openmoko_SMS_Middleware (ideas and wishes)
http://code.google.com/p/sms-middleware/ (source code, buglist, etc.)
Openmoko SMS Middleware

Flexible answering machine

Student
Frederik Sdun
Mentor
Thomas Wood
Project page
http://code.google.com/p/robgsoc/

A targeted SELinux Policy for Openmoko

Student
Willis Vandevanter
Mentor
Stefan Schmidt
Project page
http://code.google.com/p/selinux-openmoko/

Openmoko Mail

Student
Vladimir Mihaylov
Mentor
Thomas Wood
Project page
http://wiki.openmoko.org/wiki/Openmoko_Mail
https://projects.openmoko.org/projects/openmoko-mail/
Openmoko Mail

Accelerometer-based Gestures

Student
Paul-Valentin Borza
Mentor
Daniel Willmann
Project page
http://projects.openmoko.org/projects/gestures
http://wiki.openmoko.org/wiki/Gestures
Gestures

IM/VoIP using Telepathy Framework

Student
Deniz Koçak
Mentor
Robert McQueen
Project page
http://tumay.projects.openmoko.org/
http://wiki.openmoko.org/wiki/Tumay

Project Name

Student
student name
Mentor
mentor name
Project page
http://projects.openmoko.org/projects/foo

English •  العربية •  Български •  Česky •  Deutsch •  Esperanto •  Eesti •  Español •  فارسی •  Suomi •  Français •  Ελληνικά •  עברית •  हिन्दी •  Magyar •  Italiano •  日本語 •  한국어 •  Nederlands •  Polski •  Português •  Română •  Русский •  Svenska •  Slovenčina •  ‪中文(中国大陆)‬ •  ‪中文(台灣)‬ •  Euskara

Retrieved from "http://wiki.openmoko.org/wiki/Summer_of_Code_2008"
Personal tools
Navigation
Community
Interactive