modeling-users

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

[Tom H. <elw...@ho...>]

>The local process would get a proxy object, that works
>like it's local, but in fact forwards all requests to a real
>  editing context that lives in the server.

Fede,

  Thanks for that input. A question - would using such a method (via Pyro, 
etc.) bind us to using clients exclusively written in Python? For example, 
if we wanted a client to be written in PHP or Java, we wouldn't be able to 
use that Distributed Objects method. Is that correct?

~Tom

_________________________________________________________________
Frustrated with dial-up? Lightning-fast Internet access for as low as 
$29.95/month. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/

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

[Federico H. <fh...@vi...>]

On Wed, 2004-03-10 at 18:45, Tom Hallman wrote:
>   Thanks for that input. A question - would using such a method (via Pyro=
,=20
> etc.) bind us to using clients exclusively written in Python? For example=
,=20
> if we wanted a client to be written in PHP or Java, we wouldn't be able t=
o=20
> use that Distributed Objects method. Is that correct?

I'm not familiar with Pyro at all, so I'm afraid I can't comment on
that. If it were properly implemented, you ought to be able to cross
language boundaries (I remember java apps could call Distributed Objects
at some point in history), but certain assumptions would have to be true
in the target language. For instance, it would have to implement some
form of true message passing, and not mere polymorphism (i.e. no C++).

	Fede

--=20
GnuPG Public Key: gpg --keyserver wwwkeys.eu.pgp.net --recv-key BD02C6E0
Key Fingerprint: 04F4 08C5 14B7 2C3D DB21  ACF8 6CF5 0B0C BD02 C6E0

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

[John L. <jo...@vi...>]

Sender: John Lenton <jo...@ma...>

On Wed, Mar 10, 2004 at 04:45:59PM -0500, Tom Hallman wrote:
> 
>  Thanks for that input. A question - would using such a method (via Pyro, 
> etc.) bind us to using clients exclusively written in Python? For example, 
> if we wanted a client to be written in PHP or Java, we wouldn't be able to 
> use that Distributed Objects method. Is that correct?

pyro es python-specific; what it does is a pickle/unpickle,
essentially. Note that as modeling stands now you can't pickle the
objects (because they're actually weakrefs), so you'd have to write an
EditingContextProxy or something like it to hide that. Once you've
done that, you are a step away from being transport-independant. Pyro
is easy, and fast, so I'd recommend using it at first; however, once
you have that working, if you find you need to use corba or xmlrpc,
you'd just have to subclass the EditingContextProxy.

  I'd like to point out that cimarron, the sub-proyect of PAPO I'm
  currently busy with, aims to do what Matthew describes: in an MVC
  triad, Modeling is the M  (the classes Modeling generates are the
  place to put the business logic), cimarron is the View, and you
  program the Controller. The idea behind cimarron is rather like that
  of anygui, in that you write the controller once, and cimarron is
  able to render it via any of a series of concrete frontends (unlike
  anygui, however, it's designed for strict MVC-like separation
  :)). We currently only have a Gtk2 frontend, but we will be adding
  at least curses and web (either via zope, or direct html generation)
  at some point in the future. It is still rather green, but we're
  already using it to reimplement PAPO's flagship proyect (Luca), so
  it should be stabilizing quickly.

  Let me point out, just in case it wasn't clear, that cimarron
  neither knows nor cares if it's dealing with local modeling objects,
  remote objects obtained via some kind of rpc, or plain python
  objects; likewise, in whatever you decide to do, this separation is
  crucial.

-- 
John Lenton (jo...@vi...) -- Random fortune:
Imitation is the sincerest form of television.
		-- Fred Allen

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

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

        Hi all,

  Sorry for jumping in the discussion so lately, I've been quite busy those
  last days.

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 from
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.

  BTW about weakrefs and pickle, I can effectively confirm that weakrefs
  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.

The other major problem will probably be that most operations, such as a
fetch(), are propagated through the object store hierarchy from an EC
down to the DatabaseContext(s), but at some point DBContext calls back
methods on the calling EC.


John: after a quick search I was not able to find any english-written
resources about papo and cimarron, is this available somewhere?



-- S=E9bastien.

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

[John L. <jo...@vi...>]

Sender: John Lenton <jo...@ma...>

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 from
> 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.
> 
>   BTW about weakrefs and pickle, I can effectively confirm that weakrefs
>   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.

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.

> John: after a quick search I was not able to find any english-written
> resources about papo and cimarron, is this available somewhere?

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.

-- 
John Lenton (jo...@vi...) -- Random fortune:
"In the long run, every program becomes rococo, and then rubble."
-- Alan Perlis

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

[Ernesto R. <er...@si...>]

Hi,

although this message does not respond exactly to the questions exposed =
here, I just wanted to comment what we do.

As with pyro, we designed our own protocol on top of  XMLRPC, that is, =
objects and other data (None, DateTime) may be transmitted from server =
to client for whichever purpose. The client has a collection of 'dump' =
objects, in 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-tier architecture. We are still developing, so =
actually we are not in production phase. (In the future we may switch to =
pyro and/or Corba).

On the other hand, modeling is able to run at once different models on =
differen servers, and with the future optimistic locks, the same model =
could run on several machines.

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 locally, will be send to the server. If you do not =
want to call the remote object, whenever an attribute is accessed, you =
can implement a proxy initialization which requests and stores locally =
all object attributes, or define a method in your framework (as we did), =
which requests a collection of attribute values for some objects (as a =
batch).


Best regsards
Erny

----- 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


> 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 =
from
> > 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 =
weakrefs
> >   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
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users
> 

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