[Tickets #11071] Re: Splitting long content into multiple messages

bugs at horde.org bugs at horde.org
Tue Mar 20 17:03:20 UTC 2012


Ticket URL: http://bugs.horde.org/ticket/11071
  Ticket             | 11071
  Updated By         | thomas at trethan.net
  Summary            | Splitting long content into multiple messages
  Queue              | Synchronization
  Version            | Git master
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |

thomas at trethan.net (2012-03-20 17:03) wrote:

1) Response 411 was not even defined, since it is commented out. I  
added RESPONSE_SIZE_REQUIRED because it reflects the correct state.  
But true, it is not used yet. I guess it should be handled in  
Command/Alert.php by creating a log entry that there was an error. I  
will have a look at this and adapt it.

2) I think you're talking about finding the right split position. It  
is not really about stripping whitespaces rather than ensuring that  
there are no whitespaces on the edges. But I agree, that the while  
loop is not very efficient. I will rewrite this.

3) I will look at this again. For sure the add/replace parts can be  
moved to a seperate function because they are quite the same. Handling  
other chunks differs a bit, but I guess it should be possible to move  
at least the code for splitting into this seperate function too.

4) It is the latter; maxObjSize defines the maximum size of a single  
object the client supports, whereas maxMsgSize defines the size of a  
single sync message (which can hold a split object). The if ensures,  
that objects that are too large for the client won't be sent at all.  
As far as I understood, clientContent holds only one object at a time  
(within the add/replace loop). clientContent is filled by  
"list($clientContent, $clientContentType, $clientEncodingType) =  
$device->convertServer2Client($c, $contentType, $syncDB);" and $c  
refers to "$c = $backend->retrieveEntry($syncDB, $suid, $ct,  
$fields[$ct]);" which should by just a single sync object. Therefore I  
think the comparison should be correct, but please correct if I'm wrong.

As written above I will implement the fixes and post another patch  
within the next days.

More information about the bugs mailing list