RFC: IPC::MMA

I would like to thank all the people in this community who helped in getting the subject module up, running, and contributed to CPAN. Anyone who would like to look at the documentation and/or try the module and comment will be thanked further.

The comment "split it into 3 parts" has already been heard, and I'll do it if someone who actually wants to use the result in production says this. Being a C/xs module, it's of reasonable size even when all in one module.

Best Regards,
cmac
www.animalhead.com

PS. tilly, this is the God module anti-pattern.

Comment on RFC: IPC::MMA

Replies are listed 'Best First'.
Re: RFC: IPC::MMA by ysth (Canon) on Feb 15, 2009 at 21:02 UTC
Links for the lazy: docs, distribution (download link). -- Online Fortune Cookie Search Office Space merchandise	[reply]
Re: RFC: IPC::MMA by jplindstrom (Monsignor) on Feb 15, 2009 at 21:04 UTC
IPC::MMA	[reply]
Re: RFC: IPC::MMA by perrin (Chancellor) on Feb 16, 2009 at 00:47 UTC
Glad to see someone picking up this idea! I encouraged Arthur (of IPC::MM) to put IPC::MM up on CPAN after he showed me some cool things he was doing with mm. Unfortunately for perl, Arthur went on to other things after eToys, so the module wasn't kept up. It's an IPC approach that has great potential.	[reply]
Re: RFC: IPC::MMA by samtregar (Abbot) on Feb 16, 2009 at 19:50 UTC
This looks very useful to me. It'd be interesting to see a caching module based on this. Would it beat Cache::FastMmap? Performance info in general would be interesting - is this faster than the other available IPC modules? Or does it just offer more features? How does it compare to using BerkeleyDB, which is pretty fast for disk-based shared storage. -sam	[reply]
Re^2: RFC: IPC::MMA by cmac (Monk) on Feb 18, 2009 at 07:20 UTC
One man (I believe he contributed to this thread) has kind of volunteered to build an interface between IPC::MMA and one of the caching modules. Although I may have forgotten to get back to him and encourage him to do this. As to performance, hopefully someone can do some benchmarking. The binary-search-based "hash" used in this module will hopefully beat a linked-list-based hash for larger numbers of key-value pairs. Don't know the exact cutover but maybe about 1000 entries? Thanks for your interest, cmac	[reply]