I've been thinking a lot lately about Kagu Media Player's future. The project has come a long way and all of us devs have learned a lot in the process. But Canola is coming out soon (or so it seems) and we're reaching the limit of what is maintainable with a pygame based UI.
<br><br>I've decided that I'd really like to separate the frontend code from the backend code so we can have multiple frontends (pygame, gtk, etk, cli, WWW, etc).<br><br>This would mean that the Kagu backend process would be a daemon (aka a service, depending on your education environment).
<br>And the frontends would communicate with the backend process somehow. I see a few possibilities here:<br><br>1.) Rpc (aka web services)<br>2.) Dbus<br>3.) Direct SQLite DB interaction<br><br>Dbus seems like an obvious choice, but Kagu would be incredibly chatty and I'm not sure if Dbus is capable of handling the bandwidth. In addition, dbus would limit GUIs to running on the device itself, rather than the world at large. This isn't necessarily a bad thing, but it's something to consider.
<br><br>SQLite is the least friendly method, IMO, as it involves file locking and other nastiness. No thanks.<br><br>Rpc seems like the best overall choice, but how common is Rpc on Maemo?<br><br><br>The other concern I have is process management of the backend Kagu daemon. How will it be started? How will it be stopped?
<br><br>A GTK, PyGame, ETK, or even CLI client could start the Kagu daemon for us. But what about a WWW client? Is there any way to start the daemon simply by accessing a URL, like <a href="http://localhost/kagu">http://localhost/kagu
</a> ? If Apache was installed on the device then an apache script (mod_php or mod_python) could start the daemon for us and proxy any requests. But that seems too bulky of a solution.<br><br>I've seen this page discussing WWW applications as local applications on Maemo:
<a href="http://maemo.org/community/wiki/serverbrowserappdevelopment/">http://maemo.org/community/wiki/serverbrowserappdevelopment/</a> But I couldn't find the mailing list discussion it references.<br><br>Any suggestions for these problems? Any ideas? Comments?
<br><br>Thanks!<br clear="all"><br>-- <br>Jesse Guardiani<br>Software Developer / Sys Admin<br><a href="mailto:jesse@guardiani.us">jesse@guardiani.us</a>