Index: openacs-4/packages/acs-authentication/www/doc/ims-sync-driver-design.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-authentication/www/doc/ims-sync-driver-design.html,v
diff -u -r1.1 -r1.2
--- openacs-4/packages/acs-authentication/www/doc/ims-sync-driver-design.html 14 Oct 2003 09:54:26 -0000 1.1
+++ openacs-4/packages/acs-authentication/www/doc/ims-sync-driver-design.html 20 Oct 2003 15:44:31 -0000 1.2
@@ -2,11 +2,11 @@
by Lars Pind
OpenACS docs are written by the named authors, and may be edited
by OpenACS documentation staff.
-
We need examples of how the communication would be done from our clients.
The "GetDocument" communications service contract could be a generic system-wide service contract.
We might need a source/ID column in the users table to identify where they're imported from for doing updates, particularly if -importing from multiple sources (or when some users are local.)
We will parse a document in the IMS Enterprise +importing from multiple sources (or when some users are local.)
We will parse a document in the IMS Enterprise Specification format (example XML document), and translate it into calls to the batch user sync API.
The document will contain either the complete user listitemst (IMS: @@ -135,7 +135,7 @@ <photo imgtype="gif"><extref>...</extref></photo> if present: HTTP GET the photo, insert it into the system. (Do we do this, then, with all users when doing a snapshot update?) -
Consolidation before the leap; IMS Enterprise 1.1: This article says that IMS Enterprise 1.1 (current version) does not address the communication model, which is critically missing for real seamless