Re: Any ideas why Axiom is acting odd?

> Not a waste at all.  Axiom really needs to work on the latest  
> version of
> PySQLite :)  This isn't pressing now, of course, but at some point  
> Divmod's
> preferred deployment platform will presumably upgrade to that  
> version and
> it'd be nice if some of our software kept working :)  This applies  
> equally
> to most anyone else using Axiom I expect.

Well, for your reference it was pysqlite 2.3.1 ...

By the way, I've got a general Axiom-related architecture question.  
I'm currently sending my Items down the wire using Twisted PB and  
pb.Copyable/pb.RemoteCopy, and they come out at the the other end as  
an object that has copies of all the attributes the client may want  
to alter (basically, all of them), it's own storeID attribute, and  
other Items it refers to get (thankfully) copied along with it. If I  
use a axiom.sequence.List, I instead send a list of storeIDs since  
presumably what it is referring to is already on the client (I  
think). The client keeps track of these in a dictionary indexed by  
storeID.

The client can edit attributes and send them back, and since I have  
the storeID I can load the original Item and alter it's attributes.

This scheme seems to work OK, but it's be nice to make use of Axiom  
on the client too. Do you think there is any way I can resurrect  
these Items (they are also pb.Copyables) on the client side as Items  
and then store them in a Store there too (maybe storing the server- 
side storeID in an attribute so I can get at it) so I can query etc.?

Has anyone on the list used axiom on the client and server side at  
the same time like this? I know it sounds like I'm trying to  
implement Zope Enterprise Objects here but this is a really common  
use case in my app - the server holds an object, with references to  
others, and the client wants to change some of the attributes and  
maybe the references too, and save it on the server again.

Robert