As far as I'm concerned, I use only Evolution opensync plugin.
And the last SVN opensync works very well.
Regards,
Le vendredi 28 mai 2010 à 19:34 -0400, Paul O'Keefe a écrit :
> Barry --> Opensync --> Google would be a great thing for the Calendar
> +Contacts....
>
>
> On Fri, 2010-05-28 at 19:17 -0400, Chris Frey wrote:
> > Hi Nicolas,
> >
> > Sorry for the delay, but thanks for the patches!
> >
> > I've applied the first two, which were obvious bugfixes. Thanks!
> >
> > As for the calendar ID patch, some issues:
> >
> > 1) Pulling data from the Blackberry should go through the btohll() macro.
> >
> > + case CALFC_CALENDAR_ID:
> > + if( btohs(field->size) == 8 ) {
> > + CalendarID = field->u.uint64;
> > + }
> > + else {
> >
> >
> >
> > 2) Calendar::Clear() should set the new CalendarID to -1 as a default,
> > instead of in the constructor, so that the user can reset
> > the record to default values himself.
> >
> >
> > 3) If I understand the logic of your patch correctly, it saves a copy
> > of one of the calendar records as it goes from BB -> VCal.
> > Then when new data comes from VCal -> BB, it uses this
> > saved record as the Calendar ID.
> >
> > What happens if there really are multiple calendars? Won't this
> > overwrite things, or potentially put certain calendar data in
> > the wrong calendar?
> >
> > What if there are no new records in the BB -> VCal direction?
> > Will the VCal -> BB step have a Calendar ID, or just the default?
> >
> > I think we need to think about how to sync multiple calendars into another
> > application. Does opensync support such a concept? I don't think it does.
> >
> > Perhaps we need a plugin config setting, to let the user decide what
> > calendar he wishes to sync, instead of just assuming a default.
> >
> > Is there an extra database in your device that lists the available
> > calendars? It would be good to add a parser for that, so we can connect
> > CalendarID's with email addresses. If you can post a 'btool -d' hex dump
> > of the records, maybe we can analyze the format together.
> >
> > - Chris
> >
> >
> > On Wed, May 26, 2010 at 07:35:07PM +0200, Nicolas wrote:
> > > Hi,
> > >
> > > I have finished my test and you find my patch in my git repository :
> > >
> > > http://repo.or.cz/w/barry/progweb.git
> > >
> > > I have splitted my commit in several steps.
> > >
> > > Work for me and should be good with older devices.
> > >
> > > Regards,
> > >
> > > Nicolas
> > >
> > >
> > >
> > > Le mardi 25 mai 2010 ?? 23:04 -0400, Chris Frey a ??crit :
> > > > On Mon, May 24, 2010 at 10:44:09PM +0200, Nicolas wrote:
> > > > > Hi Chris,
> > > > >
> > > > > I have noticed two little issues.
> > > > >
> > > > > First, in :
> > > > > void BuildField(Data &data, size_t &size, uint8_t type, uint32_t
> > > > > value)
> > > > > I read :
> > > > > uint32_t store = htobs(value);
> > > > > inside of :
> > > > > uint32_t store = htobl(value);
> > > >
> > > > Hi Nicolas,
> > > >
> > > > That looks like a true bug. Good catch! I would accept a patch just
> > > > to fix that, if you want. I notice that your git repo says that
> > > > your current patch isn't ready to be included yet.
> > > >
> > > >
> > > > > Second, SetRecordByIndex replaces some fields even if I haven't set a
> > > > > new values. So I can lose some informations.
> > > > > Sample, in calendar we have to set the CalendarID field (new field see
> > > > > my git) otherwise, the event is moved in default calendar :(
> > > > >
> > > > > Read my patch and most of my comment in GIT, I think that you
> > > > > understand
> > > > > the issue.
> > > >
> > > > I see that you've added an extra 64 bit BuildField. That's fine with
> > > > me too.
> > > >
> > > > I don't see the change in SetRecordByIndex().
> > > >
> > > > I don't have a new device, so I can only determine where the new
> > > > CalendarID
> > > > field is based on your parsing code. It looks like it is part of the
> > > > record data itself. So you are correct to add another class member to
> > > > the
> > > > Calendar record class.
> > > >
> > > > I am hoping that there is a default value for CalendarID. The
> > > > constructor
> > > > should set this default value, and if the value is still default when
> > > > building the record, it should skip it, in order to be backward
> > > > compatible
> > > > with older devices.
> > > >
> > > > - Chris
> > > >
> > > >
> > > > ------------------------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > Barry-devel mailing list
> > > > Barry-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/barry-devel
> > > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Barry-devel mailing list
> > > Barry-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/barry-devel
> >
> > ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Barry-devel mailing list
> > Barry-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/barry-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Barry-devel mailing list
> Barry-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/barry-devel
>
------------------------------------------------------------------------------
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
