Totally agree on all points. So far my first concern has been the plugin, but I'll try to keep the whole Barry package in mind as I submit updates. Go ahead and work out the changes if you have time; I'll be out on biz travel next week. Otherwise, I don't mind making the edits. I'm a bit if a nit-picker myself.
What I *really* want to do is get recurring events going 100%... -Lee On Wed, 2008-08-13 at 00:51 -0400, Chris Frey wrote: > On Fri, Aug 08, 2008 at 05:45:20PM -0400, Lee Dixon wrote: > > Attached is a patch file, and the associated files that were changed, to > > support birthday in the Barry::Contact and for syncing in the opensync > > plugin. > > Did some testing on the 8120 today, and played around with the Birthday > and anniversary field. I've applied your patch, but as a result of my > testing with the Blackberry, it is not ideal, and I'll probably rewrite > some of it, unless you beat me to it. :-) Let me know what your plans > are. > > Here's my reasoning: > > - nit-pick: Barry is a C++ library, and so far has avoided using > sscanf and friends, and even printf to some extent... > wherever possible, strings are formatted using the stringstream > classes, so that static fixed-size buffers like char buf[32] > are avoided... this is the direction I'd like to keep going > if possible, although in the case of this patch, sscanf > seems the simplest way to do it :-) > > Sometimes I favour safety over convenience though. > > - in testing on the 8120, the Blackberry firmware does no verification > of the date... if I enter 20/1/1999 via USB, it reads as > Jan 20, 1999 as expected, but if I use 1/20/1999, it will > just adjust the date like mktime() does, and display > something like Aug 1, 2000. > > On older devices, like my 7700 series, I was able to put > any string in, like "hey 2008", or similar... this is > something the Barry library must guard against. > > - on older devices, you can store a Birthday field via USB, but it > won't display or edit via the device itself. > > - using a string for the Birthday in the Contact class offers no > clue to the programmer what format to use, and provides > no safety mechanism to avoid mistakes... I'd rather use > a struct here, so it lets the programmer use convenient > C++ syntax to deal with a date, and lets the library deal > with the device and its peculiarities. > > I haven't decided what is best yet... it'll be either: > > - time_t > - struct tm > - or a custom struct with only 3 small fields > > Whatever is chosen here will be reused for the Anniversary > field. > > - any convenience conversion functions, for example, from struct > to string and back, should be formalized in the Contact > class, so all programs based on Barry have access to them, > instead of just in the plugin > > Looks like you've accidentally stumbled onto a tricky field as your > first patch, but it's a good thing, since it didn't exist until you > came along. :-) > > Thanks! > - Chris > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Barry-devel mailing list > Barry-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/barry-devel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
