andyg;617467 Wrote: 
> On Mar 12, 2011, at 4:00 AM, pippin wrote:
> 
> > Let's face it: the fundamental problem here (which you and I can't
> > change right now, I'm aware of that) is that there is absolutely no
> > documentation about how things _should_ work but we all - you,
> > Logitech, me, other 3rd party developers - are fudging up a system
> that
> > somehow works by incidence and as soon as _anything_ changes it can
> > break something.
> 
> Well I would say the 7.5.4 situation is not typical, we had to add
> long-polling comet support and it happened to break streaming comet for
> a short time. And gzip was also added to improve efficiency (but this
> shouldn't have broken anything).  I'm actually surprised it causes
> problems on iOS as I would hope the OS HTTP client would abstract that
> all away for you.
Actually that seems to work for me.

bluegaspode;617491 Wrote: 
> One cannot use the highlevel iOS networking classes as they sometimes
> decide to cache the comet chunks and don't hand them over for
> processing instantly.
> So I'm using a low level HTTP-class and was not aware that it sends the
> gzip headers but does not decompress automatically. Have a working
> version now but need to wait 5-10 days until Apple reviews. Turning on
> comet debug log helps because this avoid the compression code on the
> sever side.

Hm, I've got no problem with that, I use CFStream and it seems to
handle the decompressionAre we talking about anything else but the
initial headers anyway (I didn't check)?


-- 
pippin

---
see iPeng, the Squeezebox iPhone remote and 
*New: iPeng for iPad*, at penguinlovesmusic.com
------------------------------------------------------------------------
pippin's Profile: http://forums.slimdevices.com/member.php?userid=13777
View this thread: http://forums.slimdevices.com/showthread.php?t=86269

_______________________________________________
squeezenetwork mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/squeezenetwork

Reply via email to