On Fri, 2007-08-03 at 11:42 -0400, Rob Crittenden wrote:
> Karl MacMillan wrote:
> > I thought that the backend of the xml-rpc library was going to be a
> > python library that the web gui would use directly. The architecture
> > would be:
> >
> > xmlrpc-client -----> xmlrpc-server -------> DS
> > krb cert
> > browser -----------> web server ----------> DS
> >
> > That eliminates all of the problems, right?
> >
> > Karl
> >
>
> Long, sorry in advance.
>
> Part of the problem I'm having is that rpcclient.py does a bit of data
> massaging. We can move some of this to the server side, it probably
> belonds there anyway (such as including extra attributes when adding a
> user). This move will be done later.
>
Agreed - if our local client library does too much then the usability of
the xmlrpc api will go down dramatically.
> But with other stuff some data conversion happens and that has to be in
> the client.
>
> As a test I copied rpcclient.py to webclient.py and updated my basic TG
> gui to use webclient.py instead. All I did was replace the server. calls
> with funcs. calls (effectively skipping the XML-RPC call). The one call
> I tested worked with no changes to the GUI code except changing the API
> names.
>
> So. I think that if we expand on this idea we can still have a
> more-or-less unified client API, but one goes through XML-RPC and one
> doesn't. The trick will be telling which is which. This is where I'm
> getting hung up.
>
> So simply copying rpcclient.py to webclient.py is obviously wrong, code
> duplication up the wazoo.
>
Now - I may just have this all wrong because I'm not familiar enough
with the details, but what I had imagined was a bit different. I assumed
that we would have a common layer underneath the xmlrpc server and web
server:
---------- --------------
| xmlrpc | | web server |
---------- --------------
------------------------------
| python serverlib.py |
------------------------------
||
||
\/
------------------------------
| DS |
------------------------------
The role of serverlib.py is to abstract away the ldap detail so that we
get calls like:
adduser(realm, userObject)
uerObject = finduser(realm, userName)
It would handle authenticating to the DS locally, ldap calls, and
provide a unified data model. That means userObject would be a python
object that has all of the 'exported' attributes of a user (including
custom attributes set by a local admin).
Both the xmlrpc and web gui would be written to this api and would
really only be concerned with the details unique to each. For the xmlrpc
server that means, really, just marshalling / unmarshalling data and
making calls to serverlib.py. The web server would just be the web
presentation layer.
Now, what seems to be concerning you is that the data model in
serverlib.py will be very similar to the data model in rpcclient.py (and
there will be some overlap in xmlrpc), correct? That seems easy to
handle if you make the data objects (like userObject above) simple
collections of data and factor out marshalling / unmarshalling to xmlrpc
and ldap. So, you get something like user.py which is shared by
serverlib.py and rpcclient.py (as in shipped in both) and used by the
xmlrpc server.
You would also have userldap.py (unique to serverlib.py) and
userxmlprc.py. Those would contain functions for doing data conversion,
etc., etc.
Does that make any sense or help in any way?
Karl