On 03/20/2012 10:57 AM, Olivier Bilodeau wrote: > The goal is not to re-do the whole thing but more to present a proof of > concept of a subset of the Admin working in a modern Perl framework / > architecture. Ahh, right, that makes more sense.
> We would like to push a portion of our logic code out of bin/pfcmd into > a module that could be queried through Web Services *and* command line. > Then have a modern admin interface that would consume the Web Services > to offer the admin functionality. Right, got it. > We considered Catalyst but our target platform (CentOS 5) doesn't seem > to support it well. We try to stick to RPM packages at all costs so this > is an additional constraint here. At this point, we were thinking about > experimenting internally with Dancer, Mojolicious and another I can't > remember now. I see. Well, perl-Catalyst-Runtime is packaged in flexbox and rpmforge for CentOS 5. Although in this case, Catalyst version is a little old, and wouldn't work with a Perl server like I mentioned below. But not too much, though. What exactly were the problems you found with Catalyst in CentOS? Although I have more experience in Catalyst, Dancer is a pretty good framework. From a quick search though, it's also only in rpmforge repo, not RedHat's/CentOS's official ones. I've never done anything in Mojolicious. Wouldn't it be a better practice to package non-core modules inside PacketFence itself? Using local::lib, for instance. That way, you'd be sure it would work on every system (CentOS 4, 5, 6, etc) the same way, because there would be the same module version. Unless you really need to use RedHat provided rpms, which, in Perl related stuff, I'm not sure it's much better than grabbing the modules directly from CPAN, anyway. (I realize I might be talking nonsense here, and if so, please forgive my ignorance! It's an honest question) > High-level shopping list: > * fully i18n, utf8 from start > * templatable > * testable > * ajaxified interface (field validation, search operations) > * flexible authentication to it (at least ldap, flat-file and > possibility for more) > * granular, per-action access control, grouped into configurable roles > * good error handling, integrated into Log4perl > * mobile version? > * can run in a separate daemon than our captive-portal > > System contraints: > * Must run on CentOS 5 (perl 5.8) > * Must be packaged upstream (CentOS, rpmforge, EPEL) or easy to package > > Out of scope: > * making it pretty > * AJAX (unless there's time) Seems a very good list, which any modern Perl framework could easily provide the necessary tools. Most of the items I have some experience with, I don't think I would have trouble coding. > As you can guess, we are basing some of our future on this rewrite of a > core component so there will be plenty of coaching from multiple members > of the team here at Inverse. That's good I guess! :) > Actually we are heading towards JSON instead right now so no SOAP::Lite > is ok. Ah, cool! > This is exactly the kind of things we would like to try as part of a > proof of concept! And having an experienced student in that area would > be invaluable for our project (we are mostly hardcore network people). Nice, I'm glad to be of any help! Thanks a lot for your answer Olivier. Just to be transparent, I'm still choosing a project, so I'm still not sure if I'll apply for PacketFence. I'm also talking to the Git community, so I don't know yet where to apply, or if I'll write two proposals, etc. Though I'm leaning towards focusing on just one. I'll let you know as soon as I make a decision. Cheers, André ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Packetfence-devel mailing list Packetfence-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-devel
