|
Frederik,
A web-service interface can co-exist with the network interface you have added.
There are some additional benefits you get with a web-service interface like:
1. Use of internet standards like xml, http, soap and firewall friendliness
2. Beagled Interface and Endpoint can be described by a WSDL: This means Beagle can participate in a SOA. Any non-Beagle service/ application can use the WSDL to figure out how to connect and invoke beagled - and be able to process results from beagled. Otherwise only a Beagle client aware of the beagle protocol and encoding can make use of a beagled service.
Imagine we have users on the Internet runnimg different search services like Beagle, GoogleDesktop etc - if each of these is described by a WSDL, then a SOA application can use the WSDL's to figure out how to connect to the search service and run search on them and aggregate results.
3. Beagled endpoints for individual users can be published and discovered from a UDDI service registry. Performance aspects of web services are being worked on: Sun is working on Fast Web Services (http://java.sun.com/developer/technicalArticles/WebServices/fastWS/), which uses binary encodings to improve performance. In due course, a standard will emerge for fast web services.
I agree that authentication is tricky issue - any authentication method we decide to use for networked beagle must be supported by the applications that allow access to the actual data - also ideally the remote user making a query to beagled should be required to authenticate only once - so that when he attempts access to data following beagle search results, he shouldn't be prompted to authenticate once again and/or authenticate differently.
Vijay
>>> Fredrik Hedberg <fredrik hedberg avafan com> 12/16/04 4:30 PM >>> Hey,
Comments inline. Vijay KN wrote: > Daniele, > > This is exactly what I have been thinking: add XML web-service support > to Beagle. A network interface does already exists in Beagle. Although the protocol is binary (uses the same marshalling as over DBus) it would be very simple to feature XML web services if you must have it in fancy XML ;). > > If we enable beagled to support XML web service interface and query > other beagled's, it can evolve into a 'distributed service'. Adding a > SOAP interface will allow beagle clients (users, applications) to query > (via xml over http) beagled service from anywhere, leveraging > 'fire-wall' friendly attribute of xml web service. Good point. However, depending on how many hits are returned from a remote user, there always lots of overhead in stuff like SOAP and other XML based protocols, it could get slow. (Beagle actually used an XML wire protocol over DBus before, but Joe ripped it out due to performance issues). > > Beagle service could then be used for new applications: > 1. Personal work-group: sooner or later users will likely have > information distributed across their office workstation, home PC and > laptops - and would like to aggregate search results from all their > different computers. > 2. Common-interest communities: (Beagle) users on the internet who share > a common interest and collaborate, could form a community and allow > real-time sharing of information they have gathered with their associates. A very cool idea Jon talked about earlier. Ideas about how to implement? > 3. Workgroup/team members within an intranet working on a common > project, can enable content to be shared with other members. Check out previous mails, network interface announcement (http://mail.gnome.org/archives/dashboard-hackers/2004-November/msg00039.html) and a second mail (http://mail.gnome.org/archives/dashboard-hackers/2004-December/msg00050.html) explaining the same thing basically. > > Beagle users could configure what resources (files, cached web pages, IM > logs ...) are searchable for queries directed to beagled web service on > their PC. Authentication, access control and transport security can make > this sharing confidential and secure. Beagle should only be used to share metadata as in search results, and obviously not the actual data. Beagle should therefor integrate with applications used to share data with coworkers (be it Samba, Apache or iFolder) for authentication of remote queries and let the other applications handle the transport. A simple "BasicAuthenticator" is in CVS as an example if you wanna do authentication integration with said applications. This is a delicate issue as far as authentication goes. We should use EDS as the certificate repository for remote authentication. The big evil company seems to have done a good job consolidating authentication/adressbook/certificates in Longhorn Contacts. But this is a classics problem, if we're the only ones using EDS certificates for authentication (and not stuff like ifolder and others), its pretty useless. Fredrik > > Vijay > > >>> Daniele Bellucci belch linux it> 12/15/04 11:48 PM >> > <mailto:belch linux it> 12/15/04 11:48 PM >>> > > |What are the concerns in having XSP running ? > it should be nice ... > but, what about using a "distributed" approach by placing a web-service on > different computer node running beagled? > > _______________________________________________ > Dashboard-hackers mailing list > Dashboard-hackers gnome org > http://mail.gnome.org/mailman/listinfo/dashboard-hackers > > > ------------------------------------------------------------------------ > > _______________________________________________ > Dashboard-hackers mailing list > Dashboard-hackers gnome org > http://mail.gnome.org/mailman/listinfo/dashboard-hackers |