Re: Standardizing data store across toolkits (SMS, PIM data, playlist, etc)
Hey, Sorry to stick my nose in on this, especially if I'm missing something. But do you guys have anything decided about this, and what it is all going to be stored on? May I suggest using SQLite for the data storage? It is very lightweight, not much ram or processor use needed, unlike parsing big XML files... and I'm sure it'd be easy implemented in the core libraries? Because this way, other applications could read from these data-stores directly, or there could be a standardized API for applications to access that could make the information available in these open formats =]. Not sure if I'm totally barking up the wrong tree here... so please correct me if I am wrong All the best, Samuel Melrose [EMAIL PROTECTED] On 20 May 2008, at 18:20, [EMAIL PROTECTED] wrote: Am Fr 16. Mai 2008 schrieb ian douglas: MartinG wrote: On Friday 16 May 2008 03:26:06 Carsten Haitzler wrote: yeah. this is actually the bigger problem we face in the longer run. standardising data stores and access to them etc. :) I think this is a important point that should be given some thought before everyone starts hacking. Would it make sense to use opensync [1] as a middle layer between the frontend app and the backend store -- with one plugin on each side? Yeah, there was a big discussion about this a few months ago, talking about whether to store data in some generic format or some homemade XML format or using some middle layer tool like opensync, and synchronizing data to a remote location periodically versus sync'ing only when connected to a PC, etc. It was a pretty thorough discussion. Personally, I like the opensync idea, a platform-independent sync engine, that can be ported to the OpenMoko platform. So was there any decision/consensus on this topic? I think it's a very mission critical thing to have a decent lib API defined from the very beginning - see KDE addressbook, other resources of Kontact and the neverending story about the *abc*-libs to use them from outside. LDAP, WebDAV/GroupDAV and even IMAP resources come to mind :-/. Have a look to Kontact|contacts|resources|add... Same thing for calendar etc... /jOERG ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Standardizing data store across toolkits (SMS, PIM data, playlist, etc)
On Wednesday 21 May 2008 12:04:40 Samuel Melrose wrote: Sorry to stick my nose in on this, especially if I'm missing something. But do you guys have anything decided about this, and what it is all going to be stored on? May I suggest using SQLite for the data storage? It is very lightweight, not much ram or processor use needed, unlike parsing big XML files... and I'm sure it'd be easy implemented in the core libraries? Because this way, other applications could read from these data-stores directly, or there could be a standardized API for applications to access that could make the information available in these open formats =]. This is one of subjects eventually being topic of the framework initiative. Right now, we have a google SoC project underway that aims to produce a dbus API and a demo-dbus PIM storage daemon to realize this. I'd be happy to discuss this further on [EMAIL PROTECTED] or [EMAIL PROTECTED] together with the GSoC student Sören Abraxa and his mentor Michael Dietrich. The current state of affairs can be read @ http://www.neo1973-germany.de/wiki/pyPimd Not sure if I'm totally barking up the wrong tree here... so please correct me if I am wrong Not at all, this is very important -- even more so if we want to realize a multicultural (UI toolkit, language, you name it) application environment. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Standardizing data store across toolkits (SMS, PIM data, playlist, etc)
Am Fr 16. Mai 2008 schrieb ian douglas: MartinG wrote: On Friday 16 May 2008 03:26:06 Carsten Haitzler wrote: yeah. this is actually the bigger problem we face in the longer run. standardising data stores and access to them etc. :) I think this is a important point that should be given some thought before everyone starts hacking. Would it make sense to use opensync [1] as a middle layer between the frontend app and the backend store -- with one plugin on each side? Yeah, there was a big discussion about this a few months ago, talking about whether to store data in some generic format or some homemade XML format or using some middle layer tool like opensync, and synchronizing data to a remote location periodically versus sync'ing only when connected to a PC, etc. It was a pretty thorough discussion. Personally, I like the opensync idea, a platform-independent sync engine, that can be ported to the OpenMoko platform. So was there any decision/consensus on this topic? I think it's a very mission critical thing to have a decent lib API defined from the very beginning - see KDE addressbook, other resources of Kontact and the neverending story about the *abc*-libs to use them from outside. LDAP, WebDAV/GroupDAV and even IMAP resources come to mind :-/. Have a look to Kontact|contacts|resources|add... Same thing for calendar etc... /jOERG ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Standardizing data store across toolkits (SMS, PIM data, playlist, etc) [Re: Software Status Update]
On Friday 16 May 2008 03:26:06 Carsten Haitzler wrote: On Fri, 16 May 2008 01:44:59 +0200 Marco Trevisan (Treviño) [EMAIL PROTECTED] babbled: Carsten Haitzler (The Rasterman) wrote: ... choose the toolkit you like. i really do not like the whole mindset of we must program in language X or use toolkit Y because the device happens to use it somewhere in some apps by default. I do agree... I always use a kind of hybrid system here (I use mixed apps both for Gnome/Kde/Xfce... Anyway a GTK/Qt mixture :P), but I've spent days to get an homogeneous look (I use Qtcurve now)... BTW, I think that there's an important thing, really more than the look one: different applications that performs the same task should work on the same dataset. I mean, if I've both an Openmoko SMS app, and a Qtopia one I want them all read the same contacts and the same messages. Maybe actually it's hard to do so, since they would use different libraries and backends, but I guess that in this middle-time we should write some syncing scripts that perform this important, vital imho, task (converting data between apps on each runtime)! yeah. this is actually the bigger problem we face in the longer run. standardising data stores and access to them etc. :) I think this is a important point that should be given some thought before everyone starts hacking. Would it make sense to use opensync [1] as a middle layer between the frontend app and the backend store -- with one plugin on each side? Or are the akonadi libraries light weight enough? Other solutions? As a poweruser I tend to want to try all and every software available to find out what fits my needs, but to set up everything from scratch each time I change my mind would be, well, boring. Programming a flexible data store on the other hand, would be rather fun (what do I know - I have never really tried (yet)) Just some free thinkin' from my side... best, MartinG [1] www.opensync.org [2] http://pim.kde.org/akonadi/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Standardizing data store across toolkits (SMS, PIM data, playlist, etc)
MartinG wrote: On Friday 16 May 2008 03:26:06 Carsten Haitzler wrote: yeah. this is actually the bigger problem we face in the longer run. standardising data stores and access to them etc. :) I think this is a important point that should be given some thought before everyone starts hacking. Would it make sense to use opensync [1] as a middle layer between the frontend app and the backend store -- with one plugin on each side? Yeah, there was a big discussion about this a few months ago, talking about whether to store data in some generic format or some homemade XML format or using some middle layer tool like opensync, and synchronizing data to a remote location periodically versus sync'ing only when connected to a PC, etc. It was a pretty thorough discussion. Personally, I like the opensync idea, a platform-independent sync engine, that can be ported to the OpenMoko platform. -id ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
