[Mailman-Developers] Re: Mailman-Developers digest, Vol 1 #442 - 12 msgs

[Bill Bumgarner]

Agreed.  I wish I had the time to fully generalize the code though I'm quite  
happy to hear that others think this is a good idea!

As it stands, it is relatively close-- the Rewrite.py module has been extended  
such that the resulting rewritten message contains instances of  
WebDAVAttachment that contain the eventual URL (archival and retrieval) for the  
attachment and the decoded raw data of the attachment.

I made the decision to call it WebDAVAttachment to imply the context within  
which it was written.  However, the actual implementation of that particular  
class has very little that is specific to WebDAV other than some of the URL  
names.  In hindsight, I really should have not prefixed the retrieval URL with  
'dav'-- it has nothing to do with DAV, even given the current implementation.

The ToArchiver Handler could clearly use some generalization!    Actually, the  
actual process() method is relatively general, but the do_dav() method should  
likely be broken out.

Applying a bit more thought to this, it strikes me that what should likely  
happen is one of several things:

- enabling/disabling different archival methods should be separated from the  
configuration of that individual archival method.   Certain archival  
configuration optiosn-- like monthly/weekly/etc (which the WebDAV stuff  
currently ignores.  I apologize for that-- more below)-- should be left in a  
sort of "global" configuration area assuming that it is appropriate to apply  
the same options to more than one archive "style".

- individual or broken out screens for the individual archival methods

- broken out mechanism that does the actual "splitting" of the archive into  
the appropriate paths.  Regardless of whether it is a filesystem or URL based  
archival mechanism, you pretty much *always* have a "root" location below which  
the entire archive resides.   The current implementation does not share any  
code between the pipermail archiver and the WebDAV archiver.   Part of this was  
because it was indicated that the pipermail stuff needed to be largely  
revisited and partially because I simply didn't have time to do the  
generalization I wanted.

---

Thomas:

	If you want to contribute to the effort prior to Barry's work  
integrating back into the core repository, I can take on the task of  
integrating your patches into my source.   Let me know and I can make sure the  
latest sources are available to you via a more direct means than the occasional  
tarball.   The changes that you indicated are certainly the correct direction  
for this codebase-- it would likely make Barry's life easier in doing the final  
to-repository integration if the code were a bit more refined.

	Ultimately, it is likely Barry's call-- I have a limited amount of  
time available now that this stuff works, but I would like to invest that time  
in ensuring that the codebase is moving as rapidly as possible into being a  
supported part of the existing Mailman infrastructure.


--

Apologies:

	These extensions were actually done as a part of the development of a  
proprietary solution for a client of CodeFab's.   Early in the specification  
phase, it become abundantly clear that leveraging Mailman would gain us a whole  
bunch of functionality for free.   Of course, the challenge was then  
convincing the client that the requirement for releasing said changes back to  
the community was a small price compared to the gain in feature set.

	This proved surprisingly easy.  The client is a very positive minded,  
forward thinking group of folks that definitely understand and believe in  
things like Open Source and Good Engineering Practices.   (If anyone is  
interested in working for such an entity in the NYC area-- with obvious ties to  
the Python community-- please let me know and I can forward your contact  
information to the appropriate individuals.  They are a "pre-IPO" "dot com"  
with excellent "potential valuation".  Yadda.).

	Our initial approach was to try and hire someone from this community  
to do the work.  Both because we wanted someone more familiar with the codebase  
than me (1.2 expiremental via cvs was my first real exposure) and because I  
really wanted to focus on other aspects of the project.

	That didn't happen and I ended up doing all the work.  Fine by me, I  
*love* programming in Python-- especially when working with a cool sourcebase.   
 However, it did mean that there was a lot of pressure on me to make the code  
work as quickly as possible and minimize the amount of effort put forth to  
making the end result as generic as it really should be.

	To give the client credit, they understand and authorized me spending  
a bunch of time to do a minimal amount of work towards a design and  
implementation that would be palatable to the community.   While they don't  
have an infinite amount of time/money to throw at this, they definitely  
recognized that an implementation that would be accepted by the community as  
rapidly as possible would benefit them, as well.

	So;   I apologize for the state of some of the code.  It is not as  
clean or as elegant as I would normally consider acceptable.

	At the same time, the work has been done, the end result actually  
works, and it is definitely a solution to a problem that has been very much at  
the forefront of a lot of folk's administrative environments.   And, of course,  
getting that initial implementation out the door is always half the battle...

	thanks,
	b.bum

/* From: Thomas Wouters <thomas@xs4all.net>  wrote */

On Fri, Feb 04, 2000 at 01:10:49PM -0500, Barry A. Warsaw wrote:
>
> >>>>> "BB" == Bill Bumgarner <bbum@codefab.com> writes:

>     BB> For the Mailman-decode-mime-file-via-webdav modifications, I
>     BB> have a relatively significant set of addtions and patches to
>     BB> Mailman.

> I'd like to take a crack at integrating the i18n changes this
> weekend.  If that goes smoothly, your stuff is next on my list.

/*
 * I'm curious about this... I've browsed through the decoding/webdav patches,
 * and it seems explicitly webdav. I understand that Bill needed webdav, and
 * has thus only worked on that, and I appreciate the effort (we might have
 * customers who want it, eventually ;) but I'm wondering if the patch can't be
 * split in two different elements; webdav archiving, and attachment-decoding,
 * and making them seperately configurable.
 *
 * I do not care about installing and configuring webdav at the moment, our
 * setup can't handle it yet, but the automatic decoding of whatever
 * word-document or powerpoint presentation our (sometimes) braindead managers
 * post to our internal all-employees mailinglists, and placing it simply as a
 * seperate file in the mailing list archive is a _very_ attractive idea. Not
 * just to me, the rest of the sysadmin departement went 'ooh' and 'ahhh' when
 * I told them about this development ;) (Which made me feel quite good, I must
 * add. I still feel I have to 'prove' python and mailman to them.)
 *
 * I have no problem with (re)writing that part of the code, of course, but I'd
 * prefer to wait until Bill's code is in the CVS tree (so that I know the
 * style/layout and general idea has been approved of ;)
 */