Re: [Modeling-users] client/server implementation

[Sebastien B. <sbi...@us...>]

        Hi,

Tom Hallman <hal...@dm...> writes:
> Greetings Sebastien and all,
>=20
>    I have a few questions regarding a client/server implementation using
> Modeling. I will do my best to make this as clear as possible =3D)
>=20
>    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 res=
ide
> on the client. When a call is made to a method on the client side that do=
es
> 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 necessar=
y.)
>=20
>    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.

> Will we lose or "dirty" important context data?
> Other than the basic member data of a class (like for an Address class: c=
ity,
> state, etc.), what data do Modeling objects maintain (I know one such thi=
ng is
> the global ID)?=20=20

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.

> 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=E9bastien.