Re: [Tracker] Tracker on a NAS

[Philip Van Hoof <spam pvanhoof be>]

On Sun, 2009-02-01 at 00:10 +0100, Diego GonzÃlez wrote:
> Hi,
>
> I have a NAS in which i store loads of documents. I would like to run
> tracker on this server to index the full contents and have this index
> exported to all the users in my network, so that they can search
> trough this contents without having to index them locally on their
> computers (thus, having a single index also exported by the server).
>
> So, basically the users would search with their local
> tracker-search-tool and results would be combined: the results of the
> search done in their local files with the result of the search done in
> the files on the NAS. I guess this would require tracker to work over
> the network or something like that.
>
> Is it possible to achieve something like this with tracker? if not, is
> this on tracker's roadmap?

Remote search isn't on Tracker's current roadmap. But any research going
in this direction is much welcomed.

We have for example during the Berlin Desktop Search Hackfest that we
held in cooperation with the Maemo Summit and Nokia been discussing the
architecture of Xesam 2.0 with this item in mind.

Specifically the statefull nature of the Xesam 1.0 structure versus the
statelessness of the Xesam 2.0 one will help a lot in this area.

We foresee for example that in future people will want to do remote
searches, and have a view on a remote Live search, using devices that
will see themselves get disconnected and reconnected (with a different
IP address) from and to the Internet.

My personal current idea is a proxy protocol for Xesam 2.0 that
communicates synchronization moments over UDP.

For example:

[E] = Significant event in life. Whether you like it or not, these
      things happen

[R] = Significant event related to the data being shown. For example a
      document that matches the live-search got added to the service.
      Therefor we must let the observers know about it (else we aren't a
      live-search service).

[I] = Protocol overhead. (technological action that makes [R] useful for
      Joe Six Pack given the realistic limitations of [E]).


[E, I, R] Client is online

[I] Client -> registration -> Service
[I] Registered client -> MD5 of state (ping keep-me-alive) -> Service
[I] Service -> ACK keep-me-alive -> registered client

[I] Service -> Synchronization -> registered client
[I] Registered client -> MD5 of state (ping back) -> Service

[E] Client goes in a tunnel or elevator and therefore looses IP
    connection with Internet provider (not uncommon for devices, not
    even if some technology evangelists try to make you believe that in
    future this wont happen. It will)

[R] Changes happen on service

[E] Client exits tunnel or elevator and therefore regains IP connection
    with Internet provider, this time different IP address

[I] Broken registered client -> MD5 of state (ping recover-me) -> Service
[I] Service -> Synchronization -> fixing broken registered client
[I] (Fixed) registered client -> MD5 of state (ping back) -> Service

[E] Time passes

[I] Registered client -> MD5 of state (ping keep-me-alive) -> Service

[R] Changes happen on service

[I] Service -> Synchronization -> registered client
[I] Registered client -> MD5 of state (ping back) -> Service

[E] Time passes

[I] Registered client -> MD5 of state (ping keep-me-alive) -> Service
[I] Service -> ACK keep-me-alive -> registered client


I know the use-case outgrows your use-case. But for this use-case I'm
quite sure that it would be possible to get commercial funding to
actually also make it all happen.

That doesn't have to mean that as a purely community effort a use-case
like yours (where a stable connection with the service is ~ guaranteed)
wouldn't be welcomed. I think it would.

But for the companies that are at this moment involved in Tracker, I
think that remote search capabilities would have to enable more than
just remotely searching things.

Notwithstanding I'm not sure. I mean ... do the research, code the code,
make a few other people excited and interested, and I'm pretty sure
it'll happen.

By that I mean that much of Tracker's roadmap is also in your hands.

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be