http://bugs.freedesktop.org/show_bug.cgi?id=12465
------- Comment #5 from [EMAIL PROTECTED] 2007-09-21 11:03 PST ------- The major problem we solve by using signals is that receiving a large avatar can take longer than the D-Bus method call timeout; once we've done the expensive part of the call (getting the avatar across the network), we might as well hand it over to the client (the cheap part of the call) even if it took so long that a method call would have timed out. Also, doing many method calls in parallel is problematic, because until very recent versions of D-Bus (which are not yet used on embedded platforms like the N800), there was a small maximum number of parallel pending calls allowed by the bus daemon (I think it was 32). > Avatars can be cached by the CM. Connection managers should not cache avatars. The Telepathy specification is meant to encode what happens in the underlying IM protocol, and connection managers are just meant to bridge between the underlying protocol and the client. The intention was always that clients are responsible for caching avatars: - clients can do this in a uniform way across all connection managers - cached avatars can be usable when no CM is running (e.g. when you're offline) - connection managers should not enforce a particular storage policy for avatars (for instance, an appropriate cache size for a desktop PC would be excessively large for an N800, and the desired location is likely to be different) - connection managers should not write to the filesystem (so they can be jailed with e.g. SELinux in future) - connection managers should not be configurable except via the D-Bus API at runtime (for simplification, and e.g. SELinux jailing) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
