[Thread Prev][Thread Next][Thread Index]

Re: Another feature I would like to see

The Pilot keeps very good track of which records have been modified,
so if nothing has been changed on the Pilot it should be very fast.
However, it's not a real portable solution to check the datestamp
of the callog file because that's probably not going to work on 
any system that doesn't use rpc.cmsd.  In fact, rpc.cmsd may go away
in some later rev of CDE and be replaced with something entirely new.

In my copious spare time, I'm looking into making SyncCM fully CDE
compliant.  It's my hope that the CSA interface to CDE calendars will
keep better track of modified records and make the whole process a
lot faster.  

As for me, I always forget that I added something to my calendar, so
I sync my Pilot whenever I'm about to leave my desk for more than a
couple of minutes...


>   This one may sound dumb, but because three other people have access to drop
>   appt's in my calendar I never know when I should sync, so I end up doing a
>   _lot_ of needless syncs.  (5-6/day, in fact.)
>   T'would be really,amazingly efficiently cool if SyncCm -- or PilotManager
>   in general -- would check the mod'date of the callog file against any cached
>   config or log file's and skip the whole thing if nothing's changed since
>   last use when going HOST -> Pilot only.  (I've verified that PilotManager/
>   SyncCM do NOT currently do this.)  There's a potential here to completely
>   avoid the need to HotSync in HOST -> Pilot only instances.
>   In fact, extending that to the front-end filtering operation in general
>   would appear to save a fair amount of time for two-way sync operations, too.
>   Likewise: Isn't there a DB "mod'date" on the Pilot DB's that could be
>   similarly checked?  Sure, in these cases you'd still need to do the HotSync,
>   but they'd go a LOT faster when there's nothing to be done (that originates
>   from the Pilot side.)
>   I may be fairly unique in this respect -- having no knowledge as to when
>   I *need* to sync, but in the general populace I'll bet that there are
>   others in my situation.  If anyone else is in this situation out there
>   please speak up.
> 							Marty
> P.S. And as in all such wonderfully-intelligent automated
> systems, there should be a way to override those smarts and
> force the complete check regardless of what the "smarts" say to
> do!  This would NOT have to be a GUI-exposed mechanism I think,
> however.
*      This is a public mailing list!      *
*  Please do not publish Sun proprietary   *
*            information here!             *

SourceForge.net Logo