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