When you are up to define a ninja file-transferish way to retrieve bulky attachments, please consider the sending case as well.

I actually kind of think that maybe storing things on disk and passing paths around might not be so bad.

Otherwise, either both telepathy-logger and Empathy have to get an inline image (say) out of Gabble via some kind of magic side-channel, or they have to collude so that the logger grabs it, saves it to disk, and then Empathy grabs it from there.

(In reply to comment #2)
> I actually kind of think that maybe storing things on disk and passing paths
> around might not be so bad.

[punting] For file transfer, too? At least some protocol stacks expect us to give them file paths.

> Otherwise, either both telepathy-logger and Empathy have to get an inline image
> (say) out of Gabble via some kind of magic side-channel, or they have to
> collude so that the logger grabs it, saves it to disk, and then Empathy grabs
> it from there.

Can this be construed as making a case for Telepathy Storage? :) Maybe working the SMS reliable storage stuff into it somehow.

(In reply to comment #3)
> (In reply to comment #2)
> > I actually kind of think that maybe storing things on disk and passing paths
> > around might not be so bad.
> 
> [punting] For file transfer, too? At least some protocol stacks expect us to
> give them file paths.

Right. And, the magic socket FT mechanism leads to issues like bug 27423, where FT observers have no idea where the file came from or went to.

> > Otherwise, either both telepathy-logger and Empathy have to get an inline image
> > (say) out of Gabble via some kind of magic side-channel, or they have to
> > collude so that the logger grabs it, saves it to disk, and then Empathy grabs
> > it from there.
> 
> Can this be construed as making a case for Telepathy Storage? :) Maybe working
> the SMS reliable storage stuff into it somehow.

Good point.

One issue that comes up when passing filenames around is: where should the files live? Who's responsible for deleting them, or not?

(In reply to comment #4)
> > Can this be construed as making a case for Telepathy Storage? :) Maybe working
> > the SMS reliable storage stuff into it somehow.
> 
> Good point.

Well, for one thing, I'm not really sure a DBus abstraction layer over a (generic) file system is worth it; the implementation will have to be shared between all Telepathy agents. Using files in POSIX sense is probably the simplest thing; on systems where FUSE is available, this can also cover lots of other possibilities.

> One issue that comes up when passing filenames around is: where should the
> files live? Who's responsible for deleting them, or not?

A different idea: maybe there should be a dedicated Telepathy component for persistent storage, which pulls data out of the transfer sockets, provides file paths upon request (probably cached files produced out of the primary store, so only intended for reading or quick copying), and informs when the files become unavailable.

Here's a branch with a sketch of replacing GPMC: http://git.collabora.co.uk/?p=user/wjt/telepathy-spec-wjt.git;a=shortlog;h=refs/heads/replace-get-pending-message-content

While I was poking at this interface anyway, I added a message-validity header, as mentioned in passing on bug 24910. I think we could use the same supersedes header discussed in bug 25636 to represent replacing the stub parts with downloaded parts, so I added that as well. I haven't really addressed the issue of how we do out-of-band content yet.

(In reply to comment #6)
> I think we could use the same supersedes
> header discussed in bug 25636 to represent replacing the stub parts with
> downloaded parts, so I added that as well.

I beg to differ here, the semantics are too different. 'Supersedes' means a new edition of a message has been received, leaving the choice of how to represent the change to the client. The message part download is a local event reflecting an automatic process.

(In reply to comment #3)
> (In reply to comment #2)
> > I actually kind of think that maybe storing things on disk and passing paths
> > around might not be so bad.
> 
> [punting] For file transfer, too? At least some protocol stacks expect us to
> give them file paths.

This, along with some proprietary development, leads me to think that passing URIs may be even better.

I can see the following benefits of this:

 * Modern Unix-based platforms already have flexible network I/O frameworks that work with URIs. Glib-based implementations can use gvfs.
 * CMs, and maybe other parties, can declare which URI schemes do they understand.
 * Simple CMs could cache received data as temporary files.
 * Implementations of less-than-ordinary protocols could pass custom URIs, and install URI plugins into the system to handle these.
 * URI plugins for gvfs or similar platform framework could provide caching (do they now?), so multiple clients don't end up retrieving same content over the network more than once.
 * (brainstorming) There could be a "spool" URI scheme for abstracted storage of transient content.

Disadvantages:

 * For some protocols, the implementation has to be spread between Telepathy and the network I/O framework that handles URIs.
 * If files are to be used, the rules of path selection are not clear (for instance, is it safe to assume that the usual tmpdir convention produces paths accessible to all local clients? XDG to the rescue?).
 * The security model and its relation to the D-bus is not clear at all.

I cherry-picked the deprecation on Bug #26838: I think everyone agrees that the method as designed (and not implemented) isn't useful, even if we don't have a good replacement.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/59.