[Twisted-Python] Data management in a Twisted application

[Robert Gravina]

Twisted and Divmod lists,

Sorry about the cross posting here - this is mainly a Twisted  
question but it involves Divmod Axiom a little too.

I'm looking for some advice about the best way to implement data  
management in my application. The way I see it, there is a "client  
does almost everything" approach, and "server does almost everything"  
approach. I'd currently using the former, but I'd like to hear some  
opinions about switching to the latter, or if there is a better  
approach you can think of.

Here are the approaches as I see them:

---

1) Client does almost everything approach

When the user logs on they get a Cacheable, which contains a list of  
Copyable objects that they will be able to add/edit/delete. These  
objects are quite complex (have list of other objects etc.). There is  
a main screen which lists the objects details.

The user can select a row, and they get a form where that can edit  
all the various attributes (obviously much more than is displayed on  
the list on the main screen), and save it to the server. The server  
calls an update method which essentially copies across all the  
attributes to the server-side Axiom Item instance which it  
represents . Using the Cacheable previously mentioned, it notifies  
all clients that an object has been updated and sends them this  
updated object. Adding new objects works in a similar way.

Problems arise with things like delete - I'd really need to set a  
flag on the server-side object when someone has it open, so that I  
can inform other users they can't delete it.

At some point I'd like to implement searching on the main interface,  
so the users can filter their list of objects. This would require me  
to build up boolean search criteria and roll my own search using the  
lists of objects.

2) Sever does almost everything

When the user logs on they get a Cacheable again, but this time the  
list is just a summary of the objects attributes, enough to populate  
the main screen list. When the user edits a row, the client requests  
the Cacheable from the server it represents (not a Copyable anymore).  
When they save, they sent the Cacheable back to the server (is this  
possible I wonder?) and copy accross all the data like before, and  
update the clients by sending them new summary data for that object  
(but not the object itself). I hope, it's possible to stop observing  
the object too.  That way, on the server I could maintain a list of  
who has the object open at the moment.

For searching, now that all the objects live on the server I could  
send my boolean search criteria and use Axiom's search facilities to  
so a proper database search. This saves my rolling me own.

Also, another bonus of this approach is if Axiom one day supports  
Live Queries (maybe I can help implement this when I get the bulk of  
this app done) I can update the clients when their query results  
changes!

---

However, it's expected the users will be searching often, so there's  
something to be said about having all the data close at hand on the  
client. Obviously, this has drawbacks too. Aside from having to  
implement my own search, I'm worried this might mean having thousands  
of objects locally might be a memory hog (but premature optimisation  
is the root of all evil, so I'll worry about this later). The search  
might by faster since there's no need to ask the server to do it, but  
since server-side search is probably going to be much faster than my  
client side search, it's hard to estimate which will be faster.

Anyway, I hope the issues here and my implementation makes sense. I'm  
torn between which approach to take, and I'd really appreciate some  
advice.

Robert