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 <[EMAIL PROTECTED]> 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@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community