Discussion:
[Modeling-users] client/server implementation
Tom Hallman
2004-03-12 15:54:01 UTC
Permalink
Greetings Sebastien and all,

I have a few questions regarding a client/server implementation using
Modeling. I will do my best to make this as clear as possible =)

Let's say we have a client and a server, with a protocol (like XMLRPC)
between them that passes along objects and their member variables.
Modeling-generated classes reside on the server, while skeleton classes that
define the same method interface as the Modeling classes reside on the
client. When a call is made to a method on the client side that does not
locally exist, it will go out to the server to use the method that is
defined there. (This way we can write really "dumb" clients when necessary.)

The most important question is this: is it possible to pass a modeling
object back and forth over the RPC transport? (a related question is, are
Modeling classes picklable?) Will we lose or "dirty" important context
data? Other than the basic member data of a class (like for an Address
class: city, state, etc.), what data do Modeling objects maintain (I know
one such thing is the global ID)? Perhaps another way of phrasing this is:
could two Modeling objects that have the same global ID and basic member
data be interchanged without side effects?

Thanks in advance for any insight!

Yours,
Tom

___________________________________________________________
Tom Hallman DiscipleMakers, Inc
***@dm.org http://www.dm.org/~hallmant
531 Brittany Dr * State College * PA * 16803 * 814-861-4591
Go therefore and make disciples of all nations (Matt 28:19)
Sebastien Bigaret
2004-03-14 12:09:02 UTC
Permalink
Hi,
Post by Tom Hallman
Greetings Sebastien and all,
I have a few questions regarding a client/server implementation using
Modeling. I will do my best to make this as clear as possible =)
Let's say we have a client and a server, with a protocol (like XMLRPC)
between them that passes along objects and their member
variables. Modeling-generated classes reside on the server, while skeleton
classes that define the same method interface as the Modeling classes reside
on the client. When a call is made to a method on the client side that does
not locally exist, it will go out to the server to use the method that is
defined there. (This way we can write really "dumb" clients when necessary.)
The most important question is this: is it possible to pass a modeling
object back and forth over the RPC transport? (a related question is, are
Modeling classes picklable?)
They are not pickable as-is, because of the weakref pointing to the EC it
holds. Now if you transport the object to the client side the weakref is
a nonsense and can be forgotten (see also: discussion about
relationships, below). But hen, if you want to be able to modify an
object on the client side and save the changes oin the server side,
you'll need to have a mechanism mapping a client with its (server-local)
EC so that the changes can be applied and saved on the server.
Post by Tom Hallman
Will we lose or "dirty" important context data?
Other than the basic member data of a class (like for an Address class: city,
state, etc.), what data do Modeling objects maintain (I know one such thing is
the global ID)?
The GlobalID is not stored in the object itself (despite the fact I've
just noticed that there is a _globalID class attribute in CustomObject,
which needs to be removed since it's useless). When needed the gid is
asked to the relevant EC, see globalID().

What about other context data? You'll probably want to overwrite the
willChange() method on the client-side: there's no EC on the clientside
to notify for changes --you can e.g. set a particular attribute on the
object so that at some point the client can save changes by sending back
to the server the data for changed objects.
Post by Tom Hallman
Perhaps another way of phrasing this is: could two Modeling
objects that have the same global ID and basic member data be interchanged
without side effects?
Yes this can be done. The only thing you really should not do is to
change an object's EC after it's been registered, then you'll be in real
trouble! Apart from that, nothing prevents you from building a
ghost-object on a client-side and exchanging local and distant object's
data: basically and from the MDL point of view there's no difference
then simply changing object's attributes.

Now another thing that comes in play are relationships and faults. I'd
recommend, when testing such distant mechanisms, to make it work w/ a
simple entity with no relationships. Then add to-one relationship (a
to-one relationship can be identified by the GlobalID for the
destination object), then to-many rels. You can also look at snapshot()
and how this method handles to-one and to-many related objects and
faults.

Last, when thinking about all this I suspect you'll need something
like an EC on the client-side as well, at least a way to map objects
with their globalIDs. For this purpose, EC.UniquingTbale will probably
be of some help --either as-is, or mmaybe simplified.

These are quick thoughts on the subject, I probably did not answer all
your questions, but I'm ready to answer your coming questions ;)

-- Sébastien.

Loading...