Python for Asset Management!

[Alex Martelli]

Mike wrote:

> thank you all for the replies, very useful!
> 
> Our system will primary handle file assets and disk tracking...it will
> all be command line at first, then different UI's will be designed...

OK, so make sure to build a separate "engine" process (I would suggest
running it as a daemon serving xml-rpc) and "UI" processes (so the GUI,
commandline, web, ..., will all be different programs which access the
same daemon server and ONLY provide user interfacing).


> We already have most of the system written in c/c++, this is okey but
> I want to add platform independance and I like the way python handles
> different libraries, and its opensource!

Sure. you can access your existing C-coded functionality via SWIG, or
C++ coded functionality with Boost (or vice versa, but I find Boost
easiest for C++ interfacing, SWIG for C interfacing, personally).


> So why dont we buy some commercial software? well, we want 100% access
> to the source, and we also want to add modules to the system for each
> new project.

Sure, why go closed source if you can avoid it.  Note that you can
also get open source software commercially if you need support &c (as
to whether you prefer to SAVE those $$$, that's a different issue).


> I will take a look at links and information you all provided, really
> useful! Advice on how to setup a system like this is also welcome,
> should I use a  server/client solution, or just clients accessing the
> backbone(db) directly? all of your feedback is interesting, user
> experience is unvaluable!

I would write the central engine as an xml-rpc server and give it
exclusive access to "the backbone db" (except for such "offline"
bulk operations as db dumps/restores, to be presumably performed
by different administrative access).  This way you can alter the
central DB without recoding all clients, etc -- the clients will
just be xml-rpc clients and you need only maintain that interface
to leave old clients unaltered.  Should the central engine ever
become a bottleneck, running it on (e.g.) a 3GHz / gargantuan
caching / multiGB fast DDR dedicated AMD-64bit box, with the DB
on a nearby similarly overblown puppy with the fastest SCSI disks, 
and a gigabit Ethernet in between, will provide you quite a bit of
headroom -- you may never feel a need to spread it over multiple
boxes with the attendand cache-consistency headaches (perhaps some
particularly nasty and strictly computational bottleneck might be
hied off, but from your description of your system you're unlikely
to ever get any).  If you DO think in terms of scalability to
thousands or tens of thousands of concurrent accesses then some
even-more-multilayered architecture may be worth considering from
the start, but I would advise against getting too ambitious in
these terms for a budding system -- there is a real risk that by
not wanting to build anything unless it can scale up by hundreds
of times you may end up not building anything useful at all...;-).


Alex