From: Andrew S. H. <ste...@ci...> - 2004-09-08 12:10:21
|
There's a complete rewrite of SPOPS in progress? Hmm. I haven't seen anything inside SPOPS that would really warrant that, but I don't know why this rewrite is happening. In generally, I just meant that the internals of SPOPS could be better segmented out. I've been toying with Ray Zimmerman's SPOPSx::Ginsu plugin and looking through that source, he's done an excellent job of commenting which points he had to modify the code copied from various methods. Basically, I was thinking that the internals of each method should be broken up as seems appropriate to allow someone to replace only parts. Right now, there are only 2 internal method calls for fetch_group({}) in SPOPS::LDAP! This is astounding for the amount of code that's there. Most other projects I've examined would have had a half dozen or more at the minimum for a piece of code like this. As for my Active Directory solution, I'll attach it to an email to the list when I get to work so you can see what I've done. The features I've added are: 1. The ability to set a custom "sizelimit". 2. Using VLV controls to get all the records requested. (This also requires the use of Sort, so I have an "order" option.) 3. A custom SPOPS::Iterator::ActiveDirectory which allows you to start iterating through the records before all have been collecting (much better on long queries). 4. I hacked in a not_objectclass setting which basically does the opposite of the objectclass setting. I think this would be better as a query_template option where you could say: query_template => "(&(!(objectclass=Computer))(objectclass=__OBJECTCLASS__)(__QUERY__))". If the solution is to be integrated into SPOPS::LDAP, then more work needs to be done. Should let the user determine whether the sizelimit enforcement is done with the Paged control or the VLV control. And some other clean up needs to be done. Regards, Sterling On Sep 8, 2004, at 3:47 AM, Kutter Martin wrote: > Hi Andrew ! > > In one case you are damn right: SPOPS requires hacking the SPOPS.pm > module > for writing additional backends. In my opinion, this is a design flaw > that > should be removed - hence I don't have collected any idea about this > by now. > > I guess your AD module is more or less a rewrite of SPOPS::LDAP. I've > been > hacking on SPOPS::LDAP for some time now - removing bugs and adding > functionality like returning sorted results - maybe this would be > something > to merge with you changes and hand it back as a rewritten SPOPS::LDAP. > > As far as I know, Vsevolod (Simon) Ilyushchenko is working on a > complete > SPOPS rewrite - maybe our ideas are something to integrate for him. > > My opinion from hanging on this list is, that Chris - though building > wonderful software - is packed with work up to the roof, so he just > doesn't > have the time to re-work subprojects like SPOPS (And he doesn't have > an LDAP > server handy - ain't that so ?). > > So, Chris - maybe you would like to "outsource" SPOPS::LDAP > maintenance for > a while ? > If someone else would join me, I'd offer to take over SPOPS::LDAP > maintenance for a limited time (say, a year). > > Regards, > > Martin Kutter > > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...]On Behalf Of > Andrew > Sterling Hanenkamp > Sent: Montag, 6. September 2004 04:40 > To: ope...@li... > Subject: [Openinteract-dev] A few extensions to SPOPS and a comment on > the PODs > > > I have a couple things, first I've come up with a new extension for > SPOPS to allow it to connect to and communicate with Active Directory > properly. I mentioned this idea on openinteract-help, but that list is > apparently dead. The major difference is that it uses queries with the > VLV control rather than plain queries because Active Directory sharply > limits the sizelimit of LDAP queries. I also added a couple minor > features to allow the exclusion of an objectClass because Microsoft > believes that Computers are Users. > > I thought I'd mention that in case the SPOPS developers would like to > comment or see the code before I upload it to CPAN. I have a few other > smaller modules for manipulating data in some nice ways that I may also > release on CPAN. > > I've also been digging through the innards of SPOPS and it ain't > pretty. The basic extension interface is really elegant, but if > someone wants to build or extend a driver (such as my Active Directory > extension or SPOPSx::Ginsu), then he's got some serious code hacking > ahead of him. I was wondering if there was any interest in patching up > the internals of SPOPS to make it more easily extensible and more > manageable. I think the framework is already elegant enough that such > changes could really make SPOPS awesome. If some of the internals were > a little better specified and a few more divisions added, extensions > could concentrate on smaller pieces of the puzzle. > > My final comment is that the SPOPS documentation is evil. It's spread > far and wide, has too many bugs, and contradictions. For example, the > Object-Rules specify that rules should not modify the columns, but then > SPOPS comes with several Tool modules which do exactly that > (SPOPS::Tool::DateConvert is the most egregious). > > Anyway, it seems to me that SPOPS is a little stagnate, but I think it > beats the pants off of the likes of Class::DBI and Alzabo. I'd like to > help in these areas as I can. I've got a project where I'm planning to > use SPOPS pretty heavily, so it'll be to my benefit to make sure SPOPS > does what I need and I'll have to extend it in a couple more spots, so > I might as well give back to the project while I'm at it. This project > will probably last for the duration of my current job, so this could > involve some long term interest (multiple years) as well. > > Cheers, > Sterling > -- > <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> > Andrew Sterling Hanenkamp > System Administration Manager > Computing & Information Sciences > Kansas State University > > http://www.cis.ksu.edu/~sterling/ > ste...@ci... > > It's not that perl programmers are idiots, it's that the language > rewards idiotic behavior in a way that no other language or tool > has ever done. -- Erik Naggum > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > openinteract-dev mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openinteract-dev > > -- <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> Andrew Sterling Hanenkamp System Administration Manager Computing & Information Sciences Kansas State University http://www.cis.ksu.edu/~sterling/ ste...@ci... It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. -- Erik Naggum |