The Concept:

The basic concept of peer servers is that users should be able to share data between eGroupWare installations.

For example, if we have two fictional eGroupWare installations. The first installation is Microsoft and the next installation is IBM. Each of the installations has two users. Microsoft has the users Bill Gates & Bob Smith. IBM has the users Sam Palmisano and George Johnson. As it currently stands information can be easily shared between members in a single eGroupWare installation. For instance Bill Gates can easily share Calendar appointments, To-Do items, Files (from the file-manager), Addresses and so on with Bob Smith. But if Bill Gates wants to share information (e.g. calendar info, addresses etc) with Sam Palmisano from IBM then we have a problem.

Peer Servers is about how we can enable two or more eGroupWare installations to be linked and then for ACL's to be set for each user and application within the installations. For instance once the Microsoft and IBM phpgw installations have been configured to work as peer servers, Bill Gates will be able to set the ACL for Sam Palmisano and vice versa. For example Bill Gates might say that Sam Palmisano has 'read' and 'edit' rights to his Calendar. Once this is set Sam Palmisano will be able to view Bill Gates calendar appointments (from within his own eGroupWare installation) and add new appointments to Bill Gate's calendar.

How the hell are we going to accomplish this? I don't know. But hopefully over time a solid spec will be thrashed out below.

Comments:

I think this is an important feature. I think there are 2 functions here, which we need to approach from different angles. First is data sharing, where the data resides on one server and is accessed by a user via another server. The second model is data sync/replication, where the data actually moves between the 2 servers.

Data Sharing

IMHO data sharing should be relatively simple to acheive, but has the potential to generate a lot of traffic. Part of the infrastructure for the functionality already exists in eGroupWare. I would propose that peer servers and clients actually become extra account types (say 'S' for server, 'C' for Client ). The system admin would create the client accounts almost the same as they do for now user accounts. For the servers the exisiting interface could be modified to allow for ACLs, which users on the local install are allowed to access the remote server. (Does this make sense)??

This model would use simple XML-RPC (or SOAP) calls to access the data. The existing n-tier model would only need minor modifications to allow this. In the bo layer a simple check of the user type would be needed in the constructor like so:

if($GLOBALS['phpgw']['user']['account_type'] != 'C')
{
   $this->so = createObject('app.so');
}
else
{
   $this->so = createObject('app.so_remote');
}

The checking ACLs on the remote system could be acheived via a acl_remote class in the API, which would be complimented by the exisiting local only class.

ralfbecker: Maybe we can archive that by a general so_remote class, which get inhirited and only have stubs for the functions to forward:

class so_remote_xyz extends so_remote
{
  function so_remote_xyz( )
  {
    $this->so_remote(); // call parent constructor
  }
  function func1($par1,$par2)
  {
    return $this->forward('func1',$par1,$par2);
  }
  function func2()
  {
    return $this->forward('func2');
  }

  // more functions to forward

  function check_perms($entry,$needed)
  {
    return $this->check_remote_perms($entry,$needed)
  }
}

That way each app with 3-tier design, would be whith very litle efford availible for shareing.

AddressBook has shareing already implemented (by milosch).

Another option to consider is the case where both groupware installations run on the same server (or at least on a nearby server - eg on the same LAN). Then a "merge the databases" approach could be taken (ie, modify the db classes to perform all queries on the databases of both peer servers, and merge the results - obviously I'm glossing over some security considerations!). This would tend to be faster (a lot faster) than doing it over XML-based web services, and also perhaps easier to implement.

Ideally, the implementation of this peer-servers system could be done (eGroupWare-style) so that we could plug multiple backends into it, including a local "db-merging" approach like this, and a more general web-services approach using XML-RPC/SOAP

milosch - We will be adding additional account types to the standard accounts classes, at this point after 1.0. THis will include server and domain accounts, merging whatever is in the interserver class, etc. Modifications to acl are in progress to facilitate this.

As for interface to egw, the primary method is to interface externally first via a direct call to the application.bo.list_methods(). This should return a list of methods and their signatures (integer/string/array i/o). This has been working for a couple of years now, and there is some basic documentation in phpgwapi/doc/xmlrpc. Here you will also find a very old document recommending a common interface standard which afaik does not yet exist.

Data Syncing/Replication

This is a more complex subject. I have initial thoughts on what is possible:

• Mail is pretty easy, anglemail (default Email) already supports multiple accounts, so just use another Email account.
• calendar has a few new features proposed:
  • ralfbecker is working on adding iCal import/export support to calendar.
• (notes)?, (todo)?, InfoLog (necessary mod-time is already, create-time will soon be availible) - not sure

Although above shows some this is possible already or very soon, these are less than optimal solutions. Instead I would propose a more general data syncing interface. This would allow the replication of data to controlled by a cron script, and use XML-RPC (or SOAP). It would also allow regular syncing with data sources/stores.

2004-02-10 joaobr
And the case where one company has two installations? May be they easily could share the same DB server. But what when both LANs do not have a connection? A sync once or twice a day (as example) would be possible with your model? Or would this be a case for the admin to do it by hand?

The Spec: