RE: [SQLObject] Three Tier apps

[<jws...@ra...>]

>I'm not sure I understand what you want to do. Do you want to be able to 
>instantiate SQLObjects (by ID?) on both sides of the network connection? 
>Would that not be contrary to isolating functionality into separate layers?

Tier 1 - Gui,wxPython or curses or html of some sort

- connects with pyro remoteing to -

Tier 2  - Business logic, SQLObject

- connects with psycopg to-

Tier 3 - Persistant storage, Postgresql

Any tier 2 -> tier 3 communicaton will occur within the context of a single
transaction, so Pyro is safe to handle pickles that contain
less-than-complete object representations, as tier 3 has exclusive control
of the external data at that point.

To clarify the business logic futher-

In addition to the standard create, read, update, and delete methods you
would normally expect to perform on objects, I have other methods that
perform complex logic specific to my application. 

Currently I have three logical layers, but tier 1 and 2 both are in the
client application. Physically, it's a two tier system.

I want to break out the business logic onto a middleware server, so the
client and  middleware will need a network protocol to tie them together.
Pyro or ICE are the two candidates, but pyro seems more Pythonic.