[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