Bug #101355 for Catalyst-Plugin-Session-Store-CHI-CHI: what's wrong with Catalyst::Plugin::Session::Store::CHI?

I couldn't make the original work. I had a long conversation on irc with matt trout and tom doran amongst others about nine months ago. It doesn't work with anything except a file. On 06/01/2015, Karen Etheridge via RT <bug-Catalyst-Plugin-Session-Store-CHI-CHI@rt.cpan.org> wrote: Show quoted text

Hi Karen, Did my email answer your question? Catalyst::Plugin::Session::Store::CHI is marked as experimental and only works with a file. The latter means it is unsuitable for load-balanced webservers. Do you want me to do anything? Can I close the ticket? All the best. Duncan Show quoted text

Or, to make it more clear: Tom and I helped you because we wanted you to be able to fix the CHI store, with our help. I don't understand how you can thank us for our help, and then completely ignore every word of it :(

Hi Matt, It's not a pointless fork. It met the needs of the customer. That's the point. I didn't reject anything out of hand with the possible exception that neither you nor Tom wanted to use memcached in front of Oracle. I rejected that because you didn't know the background to the project. It was true. You didn't, and still don't, know the background. I spent a ridiculous amount of time on the other issues we discussed. The new module is in the Store::CHI namespace because it was originally intended to be a subclass of Store::CHI.pm. That module is written as though it expects a sub-class for every type of connection. File.pm exists. It's probably expects a DB.pm and a Redis.pm and so on. I don't think the author has got as far considering dual caches. We discussed using the Catalyst module Delegate.pm as part of a new module or within/beside the existing one. I think the problem is that the session handling sits within the model, takes data flows from the model and passes data flows to the model. You also have sub-classes of Catalyst::Model and other classes which can be referred to a models because they form part of the model. The author of the documentation is not a native English speaker and I think describing it defeated him. It certainly defeated me. I spent a long, long time with the definition of the generic delegate design pattern, the POD for Delegate.pm and the DBIC module which actually uses the Delegate, all in front of me. I still couldn't make it work. The session handling is already forked, or at least duplicated. There is a Plack session handler for CHI which can, presumably, be patched into Catalyst. I had a quick look at that. I gave up when the example code wouldn't run. I'm not naïve as a programmer. I'm very experienced and I like to think I'm reasonably competent. I've been programming in Perl for nearly 15 years now, and I've been working with Catalyst since 2010. This stuff is hard to fathom. My module has been in production on a reasonably large system since September. It's proven for the use-case given. I'd like to think it works for other use cases. If you really don't think it's useful then I am willing to delete it from CPAN. It was required for use internally, it doesn't have to be on CPAN. I don't mind working with you to fix the other module or to document Delegate.pm or whatever. However, I'm unlikely to be able to devote such a big chunk of time again. What does the author of Catalyst::Plugin::Session::Store::CHI think of all this? All the best. Duncan Show quoted text