Re: BerkeleyDB cache for webservice

2007-04-05 Thread Jeff Pang
>There's no issue with the way perl runs on linux -- the issue is the >support the distros have for it. If you're running linux, you're >building mod_perl from source. Otherwise, ModPerl on linux is just a >shame. The distros are just not supporting it. > Got it,thanks. It's not the probl

Re: BerkeleyDB cache for webservice

2007-04-05 Thread Jonathan Vanasco
On Apr 5, 2007, at 10:18 PM, Jeff Pang wrote: I never knew this point that mod_perl support Linux platforms worse. This is maybe a bad news since we have been runing hundreds of RH Linux boxes. Can you show me more reasons why mod_perl support on Linux are bad? Thanks. Its not the linux pla

re: BerkeleyDB cache for webservice

2007-04-05 Thread Jeff Pang
>i think the mod_perl support on the 'enterprise linux' platforms are >pretty bad -- they're often way out of date. public distros, like >ubuntu, are usually up-to date. >freebsd support is the best, much thanks to philip porting to >freebsd within minutes of the source code release (btw,

Re: BerkeleyDB cache for webservice

2007-04-05 Thread David Nicol
On 4/5/07, Nils Kaiser <[EMAIL PROTECTED]> wrote: Hello, we are using a webservice to check if a user agent is a mobile or full browser. We have to integrate this on the root path of a site to redirect mobile browsers to a mobile page. I'm a little but stunned that mobile browsers don't ide

Re: BerkeleyDB cache for webservice

2007-04-05 Thread Perrin Harkins
On 4/5/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote: with bdb on a single machine, you're still apt to run into time issues from locking by competing apache children on the bdb Sure, but the alternatives all use some kind of locking too. BDB handles locking as efficiently as anything I think

re: BerkeleyDB cache for webservice

2007-04-05 Thread Jonathan Vanasco
Nils Kaiser <[EMAIL PROTECTED]> > we are using a webservice to check if a user agent is a mobile or full > browser. We have to integrate this on the root path of a site to > redirect mobile browsers to a mobile page. I haven't had an issue with berkeley db since 4.2 , however there are db lo

Re: BerkeleyDB cache for webservice

2007-04-05 Thread Perrin Harkins
On 4/5/07, Jeff Pang <[EMAIL PROTECTED]> wrote: I've used both (DB_File and memcached),but I found memcached was faster than DB_File since memcached used memory as the cache device but DB_File used local filesystem.Am I not right?:) No, BerkeleyDB is significantly faster than memcached. It u

Re: BerkeleyDB cache for webservice

2007-04-05 Thread Jeff Pang
> >It's slower than BerkeleyDB and Cache::FastMmap. > I've used both (DB_File and memcached),but I found memcached was faster than DB_File since memcached used memory as the cache device but DB_File used local filesystem.Am I not right?:) -- mailto: [EMAIL PROTECTED] http://home.arcor.de/je

Re: BerkeleyDB cache for webservice

2007-04-05 Thread Perrin Harkins
On 4/5/07, Jeff Pang <[EMAIL PROTECTED]> wrote: Just give another suggestion.How about memcached? It's slower than BerkeleyDB and Cache::FastMmap. If you need your cache to work across multiple machines, memcached is a good idea. For a single machine, there's no reason to use it. - Perrin

Re: BerkeleyDB cache for webservice

2007-04-05 Thread Perrin Harkins
On 4/5/07, Nils Kaiser <[EMAIL PROTECTED]> wrote: 1) BerkeleyDB: Is berkeleyDB the best solution here? we decided to go for berkeley because of performance aspects and the maturity of the project (tools for database recovery). We want to deliver a generated cache to our customers, so beeing abl

Re: SOAP::Lite / processing complex data types at server side

2007-04-05 Thread Robert Landrum
Tobias Regneri wrote: Given the following xml structure of the data to process Name1 Val1 Name2 Val2 SOAP::Lite will build the internal representation $VAR1 = [ bless( { 'ListItem' => [ bles

Re: BerkeleyDB cache for webservice

2007-04-05 Thread Jeff Pang
-Original Message- >From: Nils Kaiser <[EMAIL PROTECTED]> > >After investigating, we decided to go for a mod_perl / berkeleydb >solution. The berkeleydb caches the data for each user agent, so the >webservice will be only queried once. Coding is not a problem as we have >one perl deve

Re: SOAP::Lite / processing complex data types at server side

2007-04-05 Thread Tobias Regneri
Raf wrote: > A quick test might be to change warn([EMAIL PROTECTED]) to: > warn($_[2]->{listItem}->[0]->{attrVal}) and see if you get 'Wert1'? Thanks for your reply, Ralf. Finally, I got it to work an hour ago. I try no more to access the parameters directly but with help of the SOAP::Server obj

BerkeleyDB cache for webservice

2007-04-05 Thread Nils Kaiser
Hello, we are using a webservice to check if a user agent is a mobile or full browser. We have to integrate this on the root path of a site to redirect mobile browsers to a mobile page. After investigating, we decided to go for a mod_perl / berkeleydb solution. The berkeleydb caches the data

Re: SOPE::Lite / prcessing complex data types at server side

2007-04-05 Thread Raf
Tobias, On Thu, 5 Apr 2007, Tobias Regneri wrote: Robert Landrum wrote: I would use Data::Dumper; warn(Dumper([EMAIL PROTECTED])); and see what's in the logs. (eval): MyProvider MyGroup attrList=HASH(0x517834) $VAR1 = \'MyProvider'; $VAR1 = \'MyGroup'; $VAR1 = \bless( { 'lis

[job] mod_perl/Catalyst in Manchester, England

2007-04-05 Thread Carl Johnstone
Hi, I work for the Guardian Media Group in their regional division based in Manchester, England. We run the websites for the groups various regional interests - mainly newspapers, but we also have a local TV station Channel M. Our flagship title is the Manchester Evening News. We're currently lo

Template Toolkit and UTF8 (was Re: UTF-8 encoding problems under Apache 2 with mod_perl 2.)

2007-04-05 Thread Clinton Gormley
I realise that you're probably not using template toolkit, but on a separate but related note: For those on the list using Template Toolkit, if your templates contain UTF8, you need to prefix them with a UTF8 BOM for them to be recognised as UTF8, otherwise TT gets really confused. See here for m