https://bugs.freedesktop.org/show_bug.cgi?id=39644
--- Comment #7 from Will Thompson <will.thompson at collabora.co.uk> 2011-11-09 08:19:04 PST ---
(In reply to comment #6)
> Since you are implementing this interface, I think that something like this
> could be supported directly by telepathy...
Jonny and I spoke about this in real life about this. There are basically four
parts of your use case:
• Discover whether the other person supports Nepomuk metadata:
This is possible with this API: you make the Handler accept a channel class
specifying ServiceName: org.kde.telepathy in it, and this will show up in
ContactCapabilities on the other side.
So:
HandlerChannelFilters = [
{ org.fd.T.Channel.ChannelType: FileTransfer,
org.fd.T.C.TargetHandleType: Contact,
},
{ org.fd.T.Channel.ChannelType: FileTransfer,
org.fd.T.C.TargetHandleType: Contact,
org.fd.T.Channel.Interface.FTMetadata.ServiceName:
'org.kde.telepathy',
},
]
• Allow the handler to set the metadata, not the offerer: unfortunately this
isn't really possible with the current API. The file offer is sent to the
peer the moment the channel is requested, and the API doesn't allow it
to be sent later. (I argued extensively for this behaviour, and I think I was
wrong.) The same problem exists for the hash: the requester has to
hash the file even if some other process is gonna send it… something to be
fixed in a future Telepathy.
• Include arbitrary metadata with the file offer: this API does support that,
but…
• Specifically sending triples: well, supporting arbitrarily-typed metadata is
not that easy. a{ss} has a pretty obvious representation in XMPP. To send
triples, we'd have to support a(sss) as well… and then it's not that clear
what to do on the wire.
a{ss}—or potentially even a{sas}—maps really easily to data forms.
With the currently-suggested API, KDE-Telepathy could send
{ "nepomuk-metadata":
"stringified representation of the triples",
}.
If we used a{sas} rather than a{ss} then it could be
{ "nepomuk-metadata":
["filename", "author is", "john",
"john", "email address is", "john at foo.com",
]
}
(that is, flattening the list of n triples into a list of 3n strings, which
lets the data retain *some* structure, if not all of it). or:
{ "nepomuk-1": ["filename", "author is", "john"],
"nepomuk-2": ["john", "email address is", "john at foo.com"],
}
It has to be a dictionary because data forms are essentially a{sas}
dictionaries.
I think it would be good in any case to make Metadata be a{sas}. Since the
on-the-wire representation, data forms, are basically that already, using that
would allow applications a smidge more structure. I think this is the only
structural complaint I have about this interface (other than acknowledging that
it's potentially onerous that only the requester can provide the metadata (and
hash)).
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.