Re: what needs to be done for beagle network

["Gregor Schmidt" <Beagle Schmidtwisser de>]

Hello dBera, hello beaglers

Thanks for your summary. Since I am one of those, who showed interest
in an soap  or better a remote interface, I'd like to comment on your
thoughts.

For me personally (1) would not help. I'd like to query beagle's index
from windows machines - a remote beagle-query or search would be to
difficult to install in cygwin. I don't now whether beagle compiles in
windows .Net because of its Gnome bindings.
Same thing for number (2)

The third one would be my favourite. First of all it enables remote
queries - it would be pretty simple to write a GUI wich uses the web
service. And these other clients may not only live on other machines,
but also in different plattforms, programming languages etc.
Everybody, wheter remote or not, would be able to use beagle as
"ultimate search engine". No more questions on how to use beagle with
php, python, c, java or whatever. Beagle could provide ONE interface
for all of them with easy integration and wide spread support and
documentation.

For that reason I had already started working on a SOAP interface for
beagle, but since my c# skills are pretty rudimentary I used Ruby. You
may find more information on the project at
https://nach-vorne.de/trac/beagle_on_rails . I think in a week, I will
have a simple SOAP interface to query beagle remotely. A web interface
is already working.

You are right, when you mention the security issues of remote
querying. The SOAP interface should provide some kind of
authentication - at least if it is called remotely. But HTTP Basic
Auth already porvides this functionality - that would do.

But I don't agree on your thoughts concerning remote access to files.
That would be an issue for the client using the
beagle-remote-interface. It may not be the task of an indexing
application to provide remote access to the indexed files. The
specific client using the interface has much better knowlegde / is
easier to configure to the special need of the concrete network
infrastructure in use. If this client enables the user to query a
server, it should also take care
of the usefullness. The same thing with the indexed e-mails or
im-logs. If the client is unable to access them it should filter them
automatically.

Sorry for the length of the mail and thanks for your attention. I
would like to help as good as I can - even if this would include
writing some c# code ;-).

Bye

Gregor

On 4/21/06, D Bera <dbera web gmail com> wrote:
> 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
> _______________________________________________
> Dashboard-hackers mailing list
> Dashboard-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/dashboard-hackers
>