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