[Bug 23160] consider not requiring clients to generate checksums for file transfers

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Aug 5 19:51:26 CEST 2009


http://bugs.freedesktop.org/show_bug.cgi?id=23160





--- Comment #2 from Dafydd Harries <dafydd.harries at collabora.co.uk>  2009-08-05 10:51:26 PST ---
(In reply to comment #1)
> 0 is nasty because we need every client implementation to implement every
> checksum known to man..

I'm not convinced it's actually that bad. We only know of one obscure algorithm
in practice.

> I propose changing to spec to separate the "provide me the file" from being
> "when the transfer is "open"" to having a special signal for that
> "PleaseProvideFile" or something.
> 
> Then use the current API.. ie give a fifo to the CM.. This has the advantage of
> being full compatible with the current API. In the AIM case, we can just emit
> PleaseProvideFile twice.
> 
> And then later when dbus 1.4 is upon us, we can add another API (ProvideFD) to
> provide the FD to the CM directly with a flag saying if its seekable or not. If
> its not seekable, then the CM can decide to re-emit the signal and get a new FD
> or something. Even in the non-hash case, that will reduce the number of context
> switches and should also improve performance.

Well, the CM doesn't need to be told whether it's seekable; it can try to seek
and ask for another one if it's not.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the telepathy-bugs mailing list