Re: what needs to be done for beagle network



On Fri, 2006-04-21 at 09:14 -0400, D Bera wrote:

> 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 ?

could we work with some kind of remap syntax on the client side? ala:
remap '/mnt/samba_share/file.txt' on the server to
'/home/$LOGIN/share/file.txt'. beagle-build-index is supposed to have
some similar functionality. 

> 
>   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 ?

the best would be to integrate beagle into existing authentification
systems (ldap, kerberos, nis, samba, whatever ...). an additional
beagle user database would be horrible. beagle returns search results on
base of the permissions retrieved from the user database.

would beagle then run as one big master daemon indexing all nfs-home
shares, samba shares etc... and deciding on the user permissions which
search results to return? to run per user one beagle daemon would be an
overkill. than it would be necessary to protect the search indexes.

greetinx
christo


> 
> 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
> 
> !DSPAM:4448dac398567500810620!
> 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]