route caching

[mla]

Kelp caches the matching patterns for a given path. If patterns contain named parameters, though, then the cache can grow without bounds.

e.g., if I have a route for /user/:id, then the cache will store something like:

          /user/1024:GET =>

          [

            bless( {

                     'regex' => qr/(?^:^\/user\/(?<id>[^\/]+)\/?$)/,

                     '_tokens' => [

                                    'id'

                                  ],

                     'param' => [

                                  '1024'

                                ],

                     'pattern' => '/user/:id',

                     'via' => undef,

                     'name' => 'user',

                     'defaults' => {},

                     'named' => {

                                  'id' => '1024'

                                },

                     'bridge' => 0,

                     'check' => {},

                     'to' => 'MyApp::user'

                   }, 'Kelp::Routes::Pattern' )

          ]

Kelp::Routes provides a cache() method, so it would be simple to inject an alternative cache object there, but I'm wondering if it

would be good to have the default setup not require that.

Looking around at the LRU cache landscape, I found Cache::LRU:

http://blog.kazuhooku.com/2010/11/cachelru-handy-and-fast-in-memory-cache.html

I know CHI is widely used, but Cache::LRU is so nice and simple. It doesn't provide a tied hash interface that I can tell, but that would be simple to add.

There's also Tie::Cache::LRU from Schwern, but he notes he's not updating it and recommends using CHI instead.

Alternatively, we could have the default setup not do caching at all, or simply clear the cache entirely when a size limit reached.

Thoughts? I think my leaning would be to have some sort of automatic expiration.

[Stefan Geneshky]

I like the idea of having the option to use a different cache modules. This way expiration can be delegated to the cache module. We need to establish a sane interface to be used, the plugging in any cache module available on CPAN should be just a matter of providing the correct roles.

If you've done any work in this direction, please share it. Otherwise, I believe I can have this done in the next few days.

Stefan

[mla]

On Monday, March 24, 2014 8:10:34 PM UTC-7, Stefan Geneshky wrote:

I like the idea of having the option to use a different cache modules. This way expiration can be delegated to the cache module. We need to establish a sane interface to be used, the plugging in any cache module available on CPAN should be just a matter of providing the correct roles.

If you've done any work in this direction, please share it. Otherwise, I believe I can have this done in the next few days.

So you're thinking something more than just a tied hash interface then? No, I haven't done any work on it yet.

Maurice

[Stefan Geneshky]

Tied hash interface is fine, but do you know of any tied hashes that do auto expiration, purging, etc.?

I was under the impression that this was the original problem we were trying to solve.

[Stefan Geneshky]

If you pull the latest code from Github, you'll see the cache implementation. It allows for a custom cache object with CHI or Cache like interface. The initialization is done in the config file, for example:

    # config.pl

    {

        modules_init => {

            Routes => {

                cache => Cache::Memory->new(

                    namespace       => 'MyApp',

                    default_expires => '3600 sec'

                );

            }

        }

    }

You can use any other cache module, as long as it has at least these three methods: get, set and clear. See Kelp::Routes POD for more information.

Stefan

[mla]

On Tuesday, March 25, 2014 11:16:24 PM UTC-7, Stefan Geneshky wrote:

If you pull the latest code from Github, you'll see the cache implementation. It allows for a custom cache object with CHI or Cache like interface. The initialization is done in the config file, for example:

Thanks, looks great.