what needs to be done for beagle network

["D Bera" <dbera web gmail com>]

Hi beaglers,
  Lately there has been a renewed interest in some sort of beagle over
network. I also sometimes feel the need of it. But there seems to be
many different goals that are being addressed and various different
solutions. It would be nice to see if there is a minimal set that can
be implemented inside beagle to give support to all of these
approaches. Since I dont understand all of them, I will list what I
understand. Please comment on which approach you think is useful and
how to go about overcoming the difficulties (maybe Joe will include
beagle-network as a SoC project ;-). Its a rather long mail, so skip
and read.

1) Allow beagle-query/beagle-search to query a beagle daemon running
over a server: There is a single server running beagle daemon and
(possibly more than one) clients running beagle-search. beagle-search
should ask the remote daemon for any query and return search results.

 Comments: Suppose beagle-search returns a file result
file:///mnt/windows/hello.txt. When the user clicks on the results,
what should happen ?
    - NFS setup: /mnt/windows/ on the server might be exported to
/windows on the client, so the file /mnt/windows/hello.txt is not
directly available to the client beagle-search. One possibility is
making beagle-search NFS-aware and do the mapping internally.
    - LAN setup: /mnt/windows/hello.txt might only be available on the server.
  Should beagle-search fetch the results (ftp/http/inhouse protocol ?)
and reveal them ? But a user might want to open the file, make some
changes and save it back to the original place. (Hmm... sounds like
beagle should include a network-transparent file-system manager ;-).
How about email queries. Should emails on the server be queryable from
the client ?

  Add to this authentication. How to solve the problems of which
clients are allowed to query a daemon, does it make sense to have
separate query-only and query-and-open permissions ?

2) Many (1)s connected in a distributed way: Similar to the
beagle-network which was implemented and then removed to give way to
webservices. Here one beagle daemon runs on each client and server.
And beagle daemons can query each other. Clients beagle-search only
queries to the local daemon which in turn distributes the query to
other daemons.

  Comments: Different ball game altogether. Implementing a
P2P/distributed system is always tricky and difficult. There are many
issues, authentication, network outages, post-processing results to
remove duplicates, control the amount of flooding, handle live query.

3) Beagle "Service": Provide a webservice which allows calling remote
beagle daemon using the standard GET, POST, SOAP (XML+RPC is a
primitive form of SOAP so thats implicitly included) bindings.

  Comments: The (now disbled) webservices part of beagle used to allow
this (at least SOAP queries). Issues like authentication are there, as
well as live-query (I dont know of any way for any HTTP server to
"push" data to a client without the client asking for it). Similar
issues regarding opening remote files/emails exist. I believe the
beagle-webservices used to be a mixture of (2)+(3). But one could talk
about directly querying a remote webservice instead of
local-client=>local-webservice=>remote=webservice.

4) Beagle CGI: This would be python/perl/php/jsp(?) and other bindings
for beagle which could be used a typical apache-type server.
Authentication can be handled using the already-available solutions
for HTTP authentication. Opening remote files can be implemented over
HTTP. Saving remote files ? Dunno ... some smart wrapper over HTTP
upload ? Again, live-queries would be tricky here. Also what to do
with non-file results ?

All 4 of the are sort of different from each other. And someone might
find one more useful over another. My personal perference is (1)
because I dont want to run a heavyweight apache like (4) and (1) is
the simplest of the rest three. But if someone implements any of the
four I will happily use it *grin*.

Please leave your comments so that someone interested knows the
possible issues and approaches. And sorry for the long email, all
these issues were so related yet different that I wasnt sure which is
the best/simplest way.

- dBera

--
-----------------------------------------------------
Debajyoti Bera @ http://dbera.blogspot.com
beagle / KDE fan
Mandriva / Inspiron-1100 user