| Summary: |
document that collaborative apps shouldn't normally use FT |
| Product: |
Telepathy
|
Reporter: |
Simon McVittie <smcv> |
| Component: |
tp-spec | Assignee: |
Telepathy bugs list <telepathy-bugs> |
| Status: |
RESOLVED
MOVED
|
QA Contact: |
Telepathy bugs list <telepathy-bugs> |
| Severity: |
enhancement
|
|
|
| Priority: |
lowest
|
|
|
| Version: |
git master | |
|
| Hardware: |
Other | |
|
| OS: |
All | |
|
| Whiteboard: |
|
|
i915 platform:
|
|
i915 features:
|
|
|---|
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Rescuing this from doc/dispatch.txt before I delete it: > File transfers might be a useful model for collaborative applications > to use to transfer snapshots of state, or to transfer related files > (e.g. in a word processor, you could receive an inline image that is > embedded in the document). This is much like dis6_. > > Additional problems: if the file transfer is part of the word processor's > IPC mechanism, then it *really* wants to get the file transfer, rather than > having another process get it as a result of a situation like dis5c_. > > Proposed implementation: Don't do this. The only case where FT-as-IPC might be appropriate is where you do want the fallback behaviour to be "save it as a file". If you send someone a Tomboy note with ContentType = "text/x-tomboy", but they don't in fact have Tomboy, then perhaps just saving a blob of text to their downloads folder is what you wanted?