Re: [Tracker] [tracker-list] network support
- From: Philip Van Hoof <spam pvanhoof be>
- To: "Zeeshan Ali (Khattak)" <zeenix gmail com>
- Cc: tracker-list gnome org
- Subject: Re: [Tracker] [tracker-list] network support
- Date: Tue, 11 May 2010 22:48:55 +0200
On Tue, 2010-05-11 at 23:27 +0300, Zeeshan Ali (Khattak) wrote:
Hi,
On Tue, May 11, 2010 at 9:26 PM, Dmitry Bashkatov <me nailgun name> wrote:
Hello!
I'm going to try to add network support for tracker. Realization will
not affect main code base. There will be daemon that sits on server
and talks to tracker-store using dbus, opening network RPC interface.
What do you think about this idea?
I think you want a UPnP MediaServer that utilizes Tracker. Rygel is
one such MediaServer: http://live.gnome.org/Rygel.
Rygel, however, will (I guess) only expose metadata about multimedia
resources. Right?
I can imagine use-cases where you want to make metadata about any other
resource available remotely. Like contacts. And where you want the rich
query experience that SPARQL provides, at the remote client.
However, I can also imagine the necessity of security and privacy
control here. We have limited support for graphs which might be useful
for this (for example: the proxy service might enforce that queries must
always request resources _in_ a specific graph, and then apps that
insert resources plus the metadata, if they want to allow remote users
to access it, can ensure that the resources they add are _in_ that
specific graph _if_ the user wants to expose it remotely).
Right now is any proxy service that will expose the SPARQL interface to
remote users going to expose _all_ of the user's metadata to whoever or
whatever remote client is authenticated to use the proxy service.
Nonetheless, it's good that Rygel already does part of the use-case for
resources that are fit for UPnp, sure.
In my opinion should Rygel too investigate how users can select which
resources are to be and which resources aren't to be exposed over, for
example, UPnp. Even for the selection "multimedia ones": let's allow the
user _not_ to expose his private videos on UPnp. The partner might not
always like that ...
Cheers,
Philip
--
Philip Van Hoof
freelance software developer
Codeminded BVBA - http://codeminded.be
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]