Re: [Modeling-users] N-tier development and modeling

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

        Hi,

  Thinking about this in the background as well ;) I've also wondered
whether simple object-proxies could do the trick for a first step toward
a distributed data layer (which I now think should ultimately be built
on top of EC, but I may change my mind in a few hours:).  And very,
very interestingly now comes Erny w/ something like a proof of concept
implementation on its side! That's very promising.

BTW is anyone here familiar w/ zodb's zeo? It's probably worth looking
at it as well.


John: I'm afraid i do not have the time to dig in cimarron's source code
now, so I think I'll wait for your short example :)

Erny: is your current impl. read-only on the client side or is it RW?
Which architecture are you using? Maybe GlobalIDs along with a map (one
client->one ec) to identify objects, and pickling (or alike) to transmit
an object's data?


-- S=E9bastien.


Ernesto Revilla <er...@si...> wrote:
> Hi,
>=20
> although this message does not respond exactly to the questions exposed h=
ere, I just wanted to comment what we do.
>=20
> As with pyro, we designed our own protocol on top of  XMLRPC, that is, ob=
jects and other data (None, DateTime) may be transmitted from server to cli=
ent for whichever purpose. The client has a collection of 'dump' objects, i=
n our words ObjectProxies, and nearly every call is a client-server-client =
transaction. Business logic resides on the server. The database can reside =
on another machine, of course. This is not very distributed, but it's a 3-t=
ier architecture. We are still developing, so actually we are not in produc=
tion phase. (In the future we may switch to pyro and/or Corba).
>=20
> On the other hand, modeling is able to run at once different models on di=
fferen servers, and with the future optimistic locks, the same model could =
run on several machines.
>=20
> In each way, if you work in a distributed environment, the implementation=
 of an object will run on one or more 'server' machines, and the 'clients' =
will hold some proxies to these objects. All method calls not treated local=
ly, will be send to the server. If you do not want to call the remote objec=
t, whenever an attribute is accessed, you can implement a proxy initializat=
ion which requests and stores locally all object attributes, or define a me=
thod in your framework (as we did), which requests a collection of attribut=
e values for some objects (as a batch).
>=20
>=20
> Best regsards
> Erny
>=20
> ----- Original Message -----=20
> From: "John Lenton" <jo...@vi...>
> To: "Modeling users' mailing list" <mod...@li...>
> Sent: Monday, March 15, 2004 2:00 PM
> Subject: Re: [Modeling-users] N-tier development and modeling
>=20
>=20
> > Sender: John Lenton <jo...@ma...>
> >=20
> > On Sun, Mar 14, 2004 at 02:37:06PM +0100, Sebastien Bigaret wrote:
> > > I must say all this is really interesting. I unfortunately do not have
> > > the time to investigate such things deeper, but i'm really interested=
 in
> > > a distributed layer. Had a very quick look at pyro, seems compact and
> > > clean. If any of you experiment in this direction I'd like to hear fr=
om
> > > the details, problems etc. As far as I can understand things, it seems
> > > that Tom and John are speaking about similar things, if not the same.
> > >=20
> > >   BTW about weakrefs and pickle, I can effectively confirm that weakr=
efs
> > >   are used, mainly in objects (which hold a weakref to their EC) and =
in
> > >   to-many faults (AccessArrayFaultHandler) which for technical reasons
> > >   hold weakref of the object referencing them.
> >=20
> > I've been thinking about this a bit (`in background', if you will),
> > and now I am of the opinion that actually using pyro on
> > editingcontexts and modeling objects is the wrong way to do this; I
> > think proxy classes (via overriding CustomObject?) is probably a saner
> > way to go. You probably don't want to shuttle your modeling objects
> > anyway: what you're wanting to distribute is the data, i.e. the result
> > of e.g. getFirstName, and possibly (although I doubt it) the effect of
> > setFirstName. Not the object itself; that would imply you are
> > distributing your business logic. I'll try to set up an example using
> > cimarron, so you can see what I mean.
> >=20
> > > John: after a quick search I was not able to find any english-written
> > > resources about papo and cimarron, is this available somewhere?
> >=20
> > papo is https://papo.vialibre.org.ar, but as you noted it's in
> > spanish. cimarron you can find in papo's savannah cvs; I'm afraid it's
> > lacking documentation and examples, and probably isn't much use
> > without a bit of handholding. However, it being a framework, we've
> > tried to keep it in english, so at least running pydoc on the files in
> > Generic/ should provide some insight. Consider it 'pre-alpha', because
> > it is.
> >=20
> > --=20
> > John Lenton (jo...@vi...) -- Random fortune:
> > "In the long run, every program becomes rococo, and then rubble."
> > -- Alan Perlis