GSoC 2008: Call for ideas

[Lally Singh]

For middleware, it looks like all that's really needed is an OM
version of Cocoa's NSNotificationCenter.  IMHO I think it's a great
place to start -- just a filtered event channel with a C-callable API
for publishing/listening for events.  I'd prefer a design that's
simple & reliable for small data packets over one that's overdesigned
for the 1% of the time when you want to transfer bulk data.

If I may suggest a starting point, something readable like XML would
be preferable over some binary representation of data.  That way,
later it could be extended to interact with web services. Also a *lot*
easier to debug, and plenty of small/simple and large/complex
libraries available to parse it.

With that said, the application API should have two layers: an
XML-based I/O layer that does all the low-level work, and a
string-based convenience library that does most jobs an app would
want, without having to make them muck around with the XML format
unless they had to get fancy.  It'll also help standardize the formats
of the events easier -- as most would just use the facilities of the
higher-level API.  Also, remember to standardize common event names
with #defines in some header files.  It'd be nice to avoid
spelling-related bugs.

The highest-level api would be something this simple:
event_listen ( POWER_MANAGER, POWER_LOW, &handle_power_low );

event_listen would call two APIs:
Document *req = build_standard_request (POWER_MANAGER, POWER_LOW);
listen_event ( req, &handle_power_low )

(Where Document is just a simple DOM tree) If someone wanted to put
together a more complex event than build_standard_request does, they
could build it themselves and send it over.  Or, event_listen could
just be equivalent to these APIs, but really just do an sprintf() and
send the result over the wire itself.  As long as both options are
available to the developer, I'm happy. The interface is what matters
to me -- the implementation is a lot easier to change once apps are
built atop of it.

It looks like another convenience API to emit a signal when an event
occurs would also be useful.   The simplest method for doing so would
be to pass a signal-emitting function into event_listen.

As for a test app, a pair of programs that talk through the middleware
would be useful.  Especially if they used different message types and
handled them differently, so that the client-side API is given a fair
shake.  Also, one as a daemon, and one as a graphical app.  Should get
the APIs pretty well vetted.


On Sun, Mar 9, 2008 at 7:00 AM, Michael 'Mickey' Lauer
<mickey at openmoko.org> wrote:
> Hi folks,
>
>  OpenMoko Inc. will apply for Google SoC 2008.
>
>  For a successfull application, we need to have a comprehensive list of ideas.
>
>  A first scratch at that is @
>  http://wiki.openmoko.org/wiki/Summer_of_Code_2008 -- please help us adding to
>  that.
>
>  Some rough guidelines:
>
>  * Please add only ideas that can be realized within the time constraints of
>  google SoC.
>
>  * Please add only ideas that end up in a software deliverable, e.g. an
>  application or a library.
>
>  * As OM lacks in middleware, please prefer middleware projects before
>  application level projects. However, as every part of middleware should be
>  application driven, the middleware deliverables should always include a demo
>  application.
>
>  I want to compile the mentoring application on Tuesday, 11th -- please make
>  sure all your great ideas are in by then.
>
>  Cheers,
>
>  Mickey.
>
>  _______________________________________________
>  OpenMoko community mailing list
>  community at lists.openmoko.org
>  http://lists.openmoko.org/mailman/listinfo/community
>



-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech