Hello. On Tue, 2008-03-18 at 07:24, Sudharshan S wrote: > > 1.) I have been working on the python-openmoko project[1], and was > wondering if its possible to extend that as part of the GSoC. The main > concern is that creating bindings for libraries that use the glib > library is pretty easy and I am not entirely sure if it would qualify as > a GSoC project on its own. However assuming that we have some more > middle ware libraries on our way, I guess its enough to keep me busy > during the summer creating example apps, documenting the library. etc.
Python bindings itself are a good idea. As you wrote yourself, just python-openmoko Alone makes no sense. Adding bindings for middleware libraries we don't have yet is also hard. ;) You can of course create a cool piece of middle ware we ware all waiting for, and *then* write bindings for it. Would be the best for us. :) As we are using also EFL these days, enhancing the python-efl bindings would make sense, too. Gustavo and the INdT doing a good job with them, but I would bet there is still stuff to do. > 2.) One of the main parts of the OM stack I am familiar with is the > "libgsmd" library on which we already has a little discussion[2] in the > gsmd lists. I feel work on libgsmd (or its replacement) should be the > top priority now and based on the discussions at the gsmd list I note > that its too early to port pygsmd (by emdete) to a C project based on > the OTAPI specs. One of the reasons[3] cited was the incomplete muxer > support. Is it possible to fix that over time and start working on ophoned. Hmm, pushing telephony forward is IMHO indeed one of the biggest points. I know that emdete is working on a userpsace muxer and I also heard rumors about work on a kernel muxer is in preparation. Sadly I don't have the final vision on this. Mickey? regards Stefan Schmidt PS: If I have missed another GSoC mail in my last roundtrip, please scream and point me to it.
signature.asc
Description: Digital signature
