Ciao!
I'm on the modper digest list so pardon the delayed response to your
input.
>>>>> "Aaron" == Aaron E Ross <[EMAIL PROTECTED]> writes:
Aaron> I've been working with a mod_perl based XML-RPC/SOAP
Aaron> service for a few months now and I thought I'd share some
Aaron> quick thoughts.
Thanks! I'll take 'um.
Aaron> As long as you are _sure_ that you won't be writing data,
Aaron> in-memory will be fast and easy to code. if you use
Aaron> objects you can pretty easily build an interface
Aaron> encouraging programmers to avoid modifying shared data.
Yes, I refuse to do *any* data arbitration between the localized
portions of the data (if any?) and the remote or official copies of it.
Copying it to a local store is meant to remove the access latency and
availability of the data, although I have not yet determined there to be
latency issues. There are however availability issues surround these
databases. I agree, an OO interface to it will facilitate its use and
certainly simplify any data format changes that are almost certain to
take place over the life of the service itself.
Aaron> Aim for what you may need later, 5+ will be easy as long as
Aaron> you have some memory.
I'm lobbying for excessive memory as we speak! Good point.
Aaron> I have found the Cache::Cache modules really easy to use,
Aaron> well written, documented and supported. MLDBM::Sync
Aaron> provides some locking, but if you really need concurrent
Aaron> access I would highly recommend BerkeleyDB,
Aaron> http://sleepycat.com/, nb this is _not_ DB_File.
Mr. Turner also mentioned the Cache::* modules for this. I'm not really
interested in locking the data in any way whatsoever. It's strictly
read-only so I see no reason to have to manage read locks. Therefore
concurrent access to an in-memory data store between all the modperl
processes should be no problem, correct?
Aaron> You haven't explained the cacheing logic at all.. perhaps
Aaron> you don't need a cache? maybe just an object that reads
Aaron> from the data stores on startup?
This is a good idea. It would eliminate the interim step of loading the
data onto the local machines prior to bringing it into memory. I'm
working on data access issues this week and want to be able to describe
the data better as well as gain query access to it. Then I should be
able to benchmark access and availability, my two primary concerns with
the data.
Aaron> If you do need a cacheing layer that updates on some event
Aaron> or expiration, remember to seperate the cacheing logic and
Aaron> the storage as much as possible to be able to tune and to
Aaron> scale up later on.
I'll keep this in mind.
Aaron> Why not write a simple object? I try to avoid tie's, b/c
Aaron> they are too "magical" for my taste, but i don't think
Aaron> there is any inherent overhead.
The object description of the data seems to be a good way to go. I
believe this will end up being the API I present to the handler for data
access. I agree.
Aaron> I would recommend using SOAP::Lite for both XML-RPC and
Aaron> SOAP. While the code is unreadable, the author is
Aaron> responsive and helpful, and the switch from XML-RPC to SOAP
Aaron> couldn't be easier.
You got the unreadable part right (c: Sorry. I've had occasion to use
Randy Ray's RPC-XML module in the past and it functioned very well. He
describes it as a reference implementation of the XML-RPC specification
and does not attest to its effeciency or speed. I'll do some comparison
shopping here with SOAP::Lite and see what comes out.
Aaron> Hope this helps, Aaron
Thanks for your insight into this matter. I really appreciate your
input.
Peace.
