[sync] Sync problem

[Joe Greco]

> > DEBUG:  Sending add from server: 20100626111600.14284swfjbo5uke8@${foo}
> >
> > [I haven't figured out how to translate those ID's to something that I
> > can retrieve for debugging.]
> 
> It the object's UID, e.g. the event_uid column in the database etc.

Okay, that's easy enough.

[...]

> > My main concern is that as it stands, there's no warning to users that
> > stuff they add won't be exported correctly via sync, and simply dropping
> > the whole record is a bit of a disaster.  I think I have to find some
> > way to address this.  I could live with the image being dropped or being
> > replaced with an error image or something.
> 
> The problem is that at the point where the size calculation happens,  
> the actual data is completely abstract to the synchronization code. It  
> could be anything and there is no way to find out which property of  
> the object made up the size overflow, let alone to remove this property.
> And it's not really *dropping* the object, it just doesn't get  
> synchronized to the sync client.

That's effectively dropping it.  Not from the Horde database, but from
the end user's view on their PDA gizmo.  That's not helpful or useful,
especially as it's essentially silent about it.  I'm not trying to be 
critical, btw, I am just pointing out an end user viewpoint.

> Unfortunately the SyncML standard doesn't provide any means to return  
> custom error messages to the client, and even for the standardized  
> errors, most clients only display some meaningless, useless error  
> message.

Yes, understood.  We deal with that in NNTP all the time here, fun
fun.

> With the new Alarm framework that has been added with Horde 3.2, we  
> might be able to store warnings for the user, so that he at least sees  
> them when logging in to Horde next time.
> But as you already notice, the *real* solution would be to implement  
> partial sending. But that costs more than a few beers. ;-)

How much more?  I have no feel here for the complexity of the code
required.  This isn't exactly mission critical here, but it does
discourage me from promoting the address book system more heavily,
and one of the reasons we picked Horde was because it did have 
functional extras like the address book, even if there are some
bugs.  :-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.