cebjyre
commented
12 years ago I choose option b!
I don't want to have a hard dependency on MooseX::ClassAttributes, but I'm certainly happy for it to use it if it is available. If you can set it up as an optional pathway that would be best, but if you've only got time to make it a required caching thing, send it across as-is and I'll be happy to have a go at hacking it up to be optional
Hi,
I use this module on the internal company portal for Bump Technologies (http://bu.mp/). This module powers our authentication system so that only people who are employees (have Google Apps accounts on our domain) can log in and access.
As implemented, this module hits Google every time you use it, even though the endpoints don't change. This breaks our employee portal since it gets enough traffic that this process is infeasible. I hacked a very basic system that writes the XML to disk so I can load it later, but that's not a good model. An in-memory hash to cache the XML with a suitable expiry of an hour or two would be grand.
I would implement it myself and give you the code, but Moose doesn't support class attributes. Two options, I guess:
a) You can implement! :) b) I can send you a pull request if you don't mind adding a dependency on MooseX::ClassAttributes.
Thanks!