From rajeevs1992 at gmail.com  Mon Aug  4 20:57:41 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Tue, 05 Aug 2014 00:27:41 +0530
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
Message-ID: <53DFD7A5.8010003@gmail.com>

Hi,

As the Summer of Code period comes to an end, I am one more step closer 
to completion of the
features mentioned in my proposal.

I have built the initial version of the backup and restore tool, that 
currently supports backup
and restore of a sqlite Mailman Instance, by archiving the var_dir to a 
zip archive.

Further, the CLI is now installable using `python setup.py install` and 
the `mmclient` command is
added to the `bin`. So the commands can now begin as `mmclient ...`

I have also replaced the `in list` filter present in the `show` 
commands, with a regular expression
matcher for better usability of the command.

I have begun code scrubbing and my primary aim will be improving the 
documentation and
more importantly, continue writing unit tests from where I left off.

I expect to complete the tasks by the suggested pencil down date 
[11/08/2014] and spend the last week
on improving the code structure, if possible anywhere.


From rajeevs1992 at gmail.com  Mon Aug  4 21:00:09 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Tue, 05 Aug 2014 00:30:09 +0530
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <53DFD7A5.8010003@gmail.com>
References: <53DFD7A5.8010003@gmail.com>
Message-ID: <53DFD839.5070903@gmail.com>


On Tuesday 05 August 2014 12:27 AM, Rajeev S wrote:
> Hi,
>
> As the Summer of Code period comes to an end, I am one more step 
> closer to completion of the
> features mentioned in my proposal.
>
> I have built the initial version of the backup and restore tool, that 
> currently supports backup
> and restore of a sqlite Mailman Instance, by archiving the var_dir to 
> a zip archive.
>
> Further, the CLI is now installable using `python setup.py install` 
> and the `mmclient` command is
> added to the `bin`. So the commands can now begin as `mmclient ...`
>
> I have also replaced the `in list` filter present in the `show` 
> commands, with a regular expression
> matcher for better usability of the command.
>
> I have begun code scrubbing and my primary aim will be improving the 
> documentation and
> more importantly, continue writing unit tests from where I left off.
>
> I expect to complete the tasks by the suggested pencil down date 
> [11/08/2014] and spend the last week
> on improving the code structure, if possible anywhere.
>

Sorry, I missed to mention that I have committed and pushed the r69 that 
carries the above changes.

Here is a link to the r69

http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/69



From stephen at xemacs.org  Wed Aug  6 08:44:45 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 06 Aug 2014 15:44:45 +0900
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <53DFD839.5070903@gmail.com>
References: <53DFD7A5.8010003@gmail.com>
	<53DFD839.5070903@gmail.com>
Message-ID: <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp>

Hi,

I have some comments on your CLI, r69.  File is attached.

Steve

-------------- next part --------------
Comments on Rajeev's CLI
========================

================== =====================================================
Comment Date:      2014-08-05 22:16
Referenced Commit: rajeevs1992 at gmail.com-20140804184004-kaan7063cifoasb1
Author:            Rajeev S <rajeevs1992 at gmail.com>
Branch Nick:       mailmancli
Commit Date:       Tue 2014-08-05 00:10:04 +0530
================== =====================================================

Tree organization
-----------------

I don't think the CLI should be buried several levels deep in the
source.  The mailman.client package is really a collection of
services, and the CLI should be at the same level in some sense.

All file references below are relative to
mailman.client/src/mailmanclient/cli.

Is there any code outside of this directory that is yours?

It's hard to recognize which files are part of this project.  This
should be reflected in header comments and/or module docstrings.  I
think that these files should also acknowledge support from Google,
and provide contact addresses (yours and mentors').

There should be a README file of some kind at the top of your subtree,
or perhaps a section in the mailman.client top level README.


mmclient.py
-----------

This file is part of your 2014 GSoC project, and not inherited from
mailman.client, right?

I think there should be some comments in this file, for example
explaining why you have what seem to be two different REPLs (c.run()
and s.cmdloop()) invoked.

It's not clear to me why you define a separate main() function in this
script -- it doesn't make sense to import it as a module.


docs
----

Run a spellchecker on these files (I saw at least one typo).

Generally they look very good: clear and complete.


lib
---

In lib/utils.py, I think there should be a more flexible way to
specify the emphasis and so on.  This is especially important for
color-blind and partially-blind users.  For now you don't need to
provide a user interface, but I'd be happier if the control sequences
were kept in module-level variables and interpolated into the messages
using %-formatting or str.format.  (Note that if you wanted to, you
could use HTML tags in such variables.  Eg, many Qt4 and Qt5 widgets
that can display text respect HTML tags in display.)

In lib/utils.py class Filter, what are the class attributes for?  They
are not used or useful.


core
----

In core/domains.py, you instantiate the Domain list then delete it,
commenting it as testing the connection.  Why does this need to be
done in the constructor?  Although Domain doesn't currently provide
any services that can be accomplished without a database query that I
noticed, so the check doesn't really hurt, it could.  (For example,
validating domain names against the syntax recommended by RFCs 822 and
1034 for mail domains.)  The same kind of service would apply to list
names.  It's also possible that there is a transient interruption that
is resolved before any actual work is done, but this check would make
the script fail.

BTW, I believe there is no need to assign self.client.domains to a
variable (the Python optimizer isn't that smart AFAIK).  Even if you
do assign, there's no need to delete the variable, as the value will
be GC'd after exiting the constructor.  IIRC, del doesn't guarantee
that the object will be GC'd any time soon, just DECREF's it.

Assuming that an HTTPError means that the operation failed in an
expected way (eg, deleting a nonexistent domain) is unacceptable.  In
particular, the transaction may fail if Mailman is stopped.  The code
must check the information provided by the HTTPError object, at least
for errors that can be expected from invalid input.  The rest can be
"Unknown HTTPError was raised" for now.

The various classes have a lot of code in common (eg, in the
__init__() and get_listing() methods).  I don't know if it's worth
refactoring because there is a lot of class-specific code in these
"lookalike" methods, but there does seem to be some potential for it.


client
------

I don't understand the parser yet, but the rest of the code looks
clean.


tests
-----

The tests look complete and properly set up.



From rajeevs1992 at gmail.com  Wed Aug  6 20:32:06 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Thu, 07 Aug 2014 00:02:06 +0530
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <53DFD7A5.8010003@gmail.com> <53DFD839.5070903@gmail.com>
 <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <53E274A6.2020205@gmail.com>

Hi Steve,


On Wednesday 06 August 2014 12:14 PM, Stephen J. Turnbull wrote:
> Tree organization
> -----------------
>
> I don't think the CLI should be buried several levels deep in the
> source.  The mailman.client package is really a collection of
> services, and the CLI should be at the same level in some sense.

I feel that it will make the code cluttered. Since the CLI code
is independent of the rest of mailman client, won't it be
better to maintain the CLI code in a separate folder, as it is now?

> All file references below are relative to
> mailman.client/src/mailmanclient/cli.
>
> Is there any code outside of this directory that is yours?

I have made modifications to setup.py, other than that, no.

> It's hard to recognize which files are part of this project.  This
> should be reflected in header comments and/or module docstrings.  I
> think that these files should also acknowledge support from Google,
> and provide contact addresses (yours and mentors').
>
> There should be a README file of some kind at the top of your subtree,
> or perhaps a section in the mailman.client top level README.
>

Will add those information in the headers by next revision.

> mmclient.py
> -----------
>
> This file is part of your 2014 GSoC project, and not inherited from
> mailman.client, right?

Yes. I created this file.

> I think there should be some comments in this file, for example
> explaining why you have what seem to be two different REPLs (c.run()
> and s.cmdloop()) invoked.
>
> It's not clear to me why you define a separate main() function in this
> script -- it doesn't make sense to import it as a module.

I was not quite familiar with using the python setuptools and I assumed 
that
such a format was necessary to specify module entry points in setup.py. I
have now removed the main function from mmclient.py

>
> docs
> ----
>
> Run a spellchecker on these files (I saw at least one typo).

Yikes! Sorry about that. Fixed at least ten of them :)

>
> Generally they look very good: clear and complete.
>
>
> lib
> ---
>
> In lib/utils.py, I think there should be a more flexible way to
> specify the emphasis and so on.  This is especially important for
> color-blind and partially-blind users.  For now you don't need to
> provide a user interface, but I'd be happier if the control sequences
> were kept in module-level variables and interpolated into the messages
> using %-formatting or str.format.  (Note that if you wanted to, you
> could use HTML tags in such variables.  Eg, many Qt4 and Qt5 widgets
> that can display text respect HTML tags in display.)

Sure. Will add that in the next revision.

> In lib/utils.py class Filter, what are the class attributes for?  They
> are not used or useful.

The Filter class is used to filter out objects meeting a certain 
condition specified by
a key, op [aka operator] and value. The filtering process works by 
iterating through each element in
the data_set and removing the objects that do not match the criterion, 
from a copy of the data_set.

The data_set cannot be used alone, as removing entries from a running 
`for i in list` loop can
cause the loop to misbehave.

The filtered copy is finally returned.

All the class attributes are being used in the process described above.

>
> core
> ----
>
> In core/domains.py, you instantiate the Domain list then delete it,
> commenting it as testing the connection.  Why does this need to be
> done in the constructor?  Although Domain doesn't currently provide
> any services that can be accomplished without a database query that I
> noticed, so the check doesn't really hurt, it could.  (For example,
> validating domain names against the syntax recommended by RFCs 822 and
> 1034 for mail domains.)  The same kind of service would apply to list
> names.  It's also possible that there is a transient interruption that
> is resolved before any actual work is done, but this check would make
> the script fail.

Now that the connection part is managed by a single function 
(Utils.connect), I
will move the connection checking part to that function. I will try to 
come up with
a better way to check for the connection, so that the mentioned possible 
issues
can be put away.

>
> BTW, I believe there is no need to assign self.client.domains to a
> variable (the Python optimizer isn't that smart AFAIK).  Even if you
> do assign, there's no need to delete the variable, as the value will
> be GC'd after exiting the constructor.  IIRC, del doesn't guarantee
> that the object will be GC'd any time soon, just DECREF's it.

Those lists were not stored into variables until some revisions back. I got
a random thought that it is a bad practice , and replaced that code with
a variable assignment. It was then when my PEP8 checker returned an error
stating the presence of an unused variable, which I solved by deleting the
assigned variable!

> Assuming that an HTTPError means that the operation failed in an
> expected way (eg, deleting a nonexistent domain) is unacceptable.  In
> particular, the transaction may fail if Mailman is stopped.  The code
> must check the information provided by the HTTPError object, at least
> for errors that can be expected from invalid input.  The rest can be
> "Unknown HTTPError was raised" for now.

Will do.

> The various classes have a lot of code in common (eg, in the
> __init__() and get_listing() methods).  I don't know if it's worth
> refactoring because there is a lot of class-specific code in these
> "lookalike" methods, but there does seem to be some potential for it.
>

I will look into the possibility of refactoring in those parts, I have 
some plans
in mind. Hope that those work!

> client
> ------
>
> I don't understand the parser yet, but the rest of the code looks
> clean.
>

I will add the grammar for each command to a README file under parsers, 
so that it
can be studied, modified or extended with ease.

> tests
> -----
>
> The tests look complete and properly set up.

Will be adding more tests shortly.

All the mentioned changes (except the tests) would be completed at the 
latest, by 9th Aug 2014, Saturday. (r 70)
Planning to spend the weekend on writing new unit tests. (r 71)

Thank You!

From stephen at xemacs.org  Thu Aug  7 08:30:17 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 07 Aug 2014 15:30:17 +0900
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <53E274A6.2020205@gmail.com>
References: <53DFD7A5.8010003@gmail.com> <53DFD839.5070903@gmail.com>
 <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53E274A6.2020205@gmail.com>
Message-ID: <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp>

Rajeev S writes:

 > I feel that it will make the code cluttered. Since the CLI code
 > is independent of the rest of mailman client, won't it be
 > better to maintain the CLI code in a separate folder, as it is now?

Of course.  I didn't explain myself well.  What you have now is

mailman/ -+- client/ -+- _client.py
                      +- docs/
                      +- tests/
                      +- cli/ -+- client.py
                               +- core/
                               +- docs/
                               +- lib/
                               +- tests/

and what I would like to see is something like

mailman/ -+- client/ -+- _client.py
          |           +- docs/
          |           +- tests/
          +- cli/ -+- client.py
                   +- core/
                   +- docs/
                   +- lib/
                   +- tests/

It's only one level higher, but it makes the relationship
(mailman.client provides services to mailman.cli) clearer, and
emphasizes the user app (cli).

 > > Is there any code outside of this directory that is yours?
 > 
 > I have made modifications to setup.py, other than that, no.

OK, that's great!

 > > It's not clear to me why you define a separate main() function in
 > > this script -- it doesn't make sense to import it as a module.
 >
 > I was not quite familiar with using the python setuptools and I
 > assumed that such a format was necessary to specify module entry
 > points in setup.py. I have now removed the main function from
 > mmclient.py

OK.  It's up to you (and maybe Barry has a stylistic opinion on it).

 > Yikes! Sorry about that. Fixed at least ten [typos] :)

And I thought I was being a cranky old man.  Glad we caught those. :-)

 > > In lib/utils.py class Filter, what are the class attributes for?  They
 > > are not used or useful.
 > 
 > The Filter class is used to filter out objects [...]
 > 
 > All the class attributes are being used in the process described above.

I don't see where.  In Filter, you have:

class Filter():
    key = None
    value = None
    operator = None
    data_set = []
    utils = Utils()

    def __init__(self, key, value, operator, data):
        self.key = key
        self.value = value
        self.operator = operator
        self.data_set = data

So as soon as you instance a Filter, __init__() creates instance
attributes which shadow the class attributes (except utils).  I don't
see any references to Filter.<attr> or to super(), so I don't see how
you can be using the class attributes.

 > Now that the connection part is managed by a single function
 > (Utils.connect), I will move the connection checking part to that
 > function.

OK.

 > Those lists were not stored into variables until some revisions back. I got
 > a random thought that it is a bad practice , and replaced that code with
 > a variable assignment. It was then when my PEP8 checker returned an error
 > stating the presence of an unused variable, which I solved by deleting the
 > assigned variable!

;-)

 > I will look into the possibility of refactoring in those parts, I
 > have some plans in mind. Hope that those work!

That would be very cool!  As I say, I'm not confident that it's worth
the work, so be careful about wasting your time just because *I* said
it.  (It's not a waste of time if you do it because you think it's an
interesting problem.)

 > All the mentioned changes (except the tests) would be completed at
 > the latest, by 9th Aug 2014, Saturday. (r 70) Planning to spend the
 > weekend on writing new unit tests. (r 71)

Sounds good!


From rajeevs1992 at gmail.com  Thu Aug  7 20:13:38 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Thu, 07 Aug 2014 23:43:38 +0530
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <53DFD7A5.8010003@gmail.com> <53DFD839.5070903@gmail.com>
 <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp> <53E274A6.2020205@gmail.com>
 <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <53E3C1D2.6070404@gmail.com>

Hi Steve,


On Thursday 07 August 2014 12:00 PM, Stephen J. Turnbull wrote:
> Rajeev S writes:
>
>   > I feel that it will make the code cluttered. Since the CLI code
>   > is independent of the rest of mailman client, won't it be
>   > better to maintain the CLI code in a separate folder, as it is now?
>
> Of course.  I didn't explain myself well.  What you have now is
>
> mailman/ -+- client/ -+- _client.py
>                        +- docs/
>                        +- tests/
>                        +- cli/ -+- client.py
>                                 +- core/
>                                 +- docs/
>                                 +- lib/
>                                 +- tests/

The above tree is wrong, this is the current directory structure

mailmanclient/ -+- _client.py
                 +- docs/
                 +- tests/
                 +- cli/  -+- mmclient.py
                           +- core/
                           +- docs/
                           +- lib/
                           +- tests/
                           +- client/


That is, the cli/ directory lives directly inside the mailmanclient directory.


>
>
> I don't see where.  In Filter, you have:
>
> class Filter():
>      key = None
>      value = None
>      operator = None
>      data_set = []
>      utils = Utils()
>
>      def __init__(self, key, value, operator, data):
>          self.key = key
>          self.value = value
>          self.operator = operator
>          self.data_set = data
>
> So as soon as you instance a Filter, __init__() creates instance
> attributes which shadow the class attributes (except utils).  I don't
> see any references to Filter.<attr> or to super(), so I don't see how
> you can be using the class attributes.

Now I get it! Will fix that.

>   > Now that the connection part is managed by a single function
>   > (Utils.connect), I will move the connection checking part to that
>   > function.
>
> OK.
>

The connection can be checked without using a database query by trying 
to invoke the
`client.system` , at a single place.

From barry at list.org  Thu Aug  7 21:07:43 2014
From: barry at list.org (Barry Warsaw)
Date: Thu, 7 Aug 2014 15:07:43 -0400
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <53DFD7A5.8010003@gmail.com> <53DFD839.5070903@gmail.com>
 <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53E274A6.2020205@gmail.com>
 <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <20140807150743.6a00a506@anarchist.wooz.org>

On Aug 07, 2014, at 03:30 PM, Stephen J. Turnbull wrote:

>Of course.  I didn't explain myself well.  What you have now is
>
>mailman/ -+- client/ -+- _client.py
>                      +- docs/
>                      +- tests/
>                      +- cli/ -+- client.py
>                               +- core/
>                               +- docs/
>                               +- lib/
>                               +- tests/
>
>and what I would like to see is something like
>
>mailman/ -+- client/ -+- _client.py
>          |           +- docs/
>          |           +- tests/
>          +- cli/ -+- client.py
>                   +- core/
>                   +- docs/
>                   +- lib/
>                   +- tests/

FWIW, my intention is to make the `mailman` package a pure namespace
package[*] so potentially lots of sourcefully-separate subpackages could live
under it.  That can't happen until Mailman 3 is a Python 3 project, but that
is still in the plans.

Cheers,
-Barry

[*]
http://legacy.python.org/dev/peps/pep-0420/
https://docs.python.org/3/reference/import.html#namespace-packages

From advax at triumf.ca  Fri Aug  8 03:53:09 2014
From: advax at triumf.ca (Andrew Daviel)
Date: Thu, 7 Aug 2014 18:53:09 -0700 (PDT)
Subject: [Mailman-Developers] Invalid HTML in mailman 2.1.18
Message-ID: <alpine.LRH.2.02.1408071809410.28139@andrew.triumf.ca>


I have wasted some time trying to get mailman 2.1.18 archives and webpages 
to pass the W3C online validator (validator.w3.org) - a probably 
pointless exercise if 2.1 is not under active development.

However, there are a few pieces of low-hanging-fruit.

- in the mailto URLs in templates, the &In-Reply-To parameter should be
   escaped to become &amp;In-Reply-To (a browser will unescape it before
   passing the URL to a mail client)
- <script> in template headers requires a content type, i.e.
   <script type="text/javascript">

- in the administration pages, HTML elements such as <table> are not
   allowed to be nested inside <address>. That's a bit harder to fix
   without changing the appearance of the pages, and most of those pages
   are not visible to the public anyway.

- in templates/*/admlogin.html and private.html, <td colspan=2 align=middle> should probably
   read <td colspan=2 align="center">

- templates/*/listinfo.html appears to have an empty <ul></ul> pair
   surrounding <MM-Subscribe-Form-Start> which the validator does not like.
   I suspect it's used to get an indent with no item marker.

- templates/*/private.html appears to have an empty <p> somewhere around
   line 40. I made the validator happy by inserting &nbsp;.


Making HTML5-compliant archives seems just about possible, HTML5 admin 
pages rather less so without effort. The rel=made header that worked with, 
I think, Lynx and maybe Mosaic is now unrecognized and useless and should 
probably be dropped altogether.

-- 
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376  (Pacific Time)

From turnbull at sk.tsukuba.ac.jp  Fri Aug  8 06:34:58 2014
From: turnbull at sk.tsukuba.ac.jp (Stephen J. Turnbull)
Date: Fri, 08 Aug 2014 13:34:58 +0900
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <53E3C1D2.6070404@gmail.com>
References: <53DFD7A5.8010003@gmail.com> <53DFD839.5070903@gmail.com>
 <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53E274A6.2020205@gmail.com>
 <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53E3C1D2.6070404@gmail.com>
Message-ID: <87k36jk39p.fsf@uwakimon.sk.tsukuba.ac.jp>

Rajeev S writes:

 > The above tree is wrong, this is the current directory structure
 > 
 > mailmanclient/ -+- _client.py
 >                  +- docs/
 >                  +- tests/
 >                  +- cli/  -+- mmclient.py
 >                            +- core/
 >                            +- docs/
 >                            +- lib/
 >                            +- tests/
 >                            +- client/
 > 
 > 
 > That is, the cli/ directory lives directly inside the mailmanclient
 > directory.

Sure, but that's not particularly important since actually it will be
the mailman.client directory when you integrate it, and (especially
after Barry's post just now) I'm pretty sure Barry intended the client
to live inside the "mailman" package.


From rajeevs1992 at gmail.com  Fri Aug  8 08:55:13 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Fri, 8 Aug 2014 12:25:13 +0530
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <87k36jk39p.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <53DFD7A5.8010003@gmail.com> <53DFD839.5070903@gmail.com>
 <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp> <53E274A6.2020205@gmail.com>
 <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp> <53E3C1D2.6070404@gmail.com>
 <87k36jk39p.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CAPq4ZOL5waPD-dhoGCK6Z2w7eZy-Mt9U2o2xC4NoKTUYCwo6zw@mail.gmail.com>

Hi Steve

On Fri, Aug 8, 2014 at 10:04 AM, Stephen J. Turnbull <
turnbull at sk.tsukuba.ac.jp> wrote:

> Rajeev S writes:
>
> ...
>
Sure, but that's not particularly important since actually it will be
> the mailman.client directory when you integrate it, and (especially
> after Barry's post just now) I'm pretty sure Barry intended the client
> to live inside the "mailman" package.
>
>
Ok. I will leave it as it is.


Further, The mmclient.py *should have* a callable function for it to work
as a module entry point (a.k.a shell command), when installed through
`python setup.py install`. The created executable does `import` the mmclient

From stephen at xemacs.org  Fri Aug  8 14:11:35 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 08 Aug 2014 21:11:35 +0900
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <CAPq4ZOL5waPD-dhoGCK6Z2w7eZy-Mt9U2o2xC4NoKTUYCwo6zw@mail.gmail.com>
References: <53DFD7A5.8010003@gmail.com> <53DFD839.5070903@gmail.com>
 <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53E274A6.2020205@gmail.com>
 <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53E3C1D2.6070404@gmail.com>
 <87k36jk39p.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAPq4ZOL5waPD-dhoGCK6Z2w7eZy-Mt9U2o2xC4NoKTUYCwo6zw@mail.gmail.com>
Message-ID: <87iom3ji4o.fsf@uwakimon.sk.tsukuba.ac.jp>

Rajeev S writes:

 > Further, The mmclient.py *should have* a callable function for it
 > to work as a module entry point (a.k.a shell command), when
 > installed through `python setup.py install`. The created executable
 > does `import` the mmclient

I still don't understand this.  You have a module whose "main
function" would perfectly servicable as "the executable" if you unwrap
it (delete the "def main" statement and fix indentation), and in fact
doesn't serve any purpose other than to be imported into a generated
script?  Seems to violate TOOWDTI to me.



From victoriano at uma.es  Fri Aug  8 20:51:32 2014
From: victoriano at uma.es (Victoriano Giralt)
Date: Fri, 08 Aug 2014 20:51:32 +0200
Subject: [Mailman-Developers] Mailman 3 RPMs anyone?
Message-ID: <53E51C34.8010100@uma.es>

Hi! it's been a long time since I wrote here (12 years according to my
archives!), but I've never stopped reading :)

I'm following with a lot of interest the progress of Mailman 3 (great job,
BTW), kudos to all devs, including the GSoC youngsters), and I've seen that
the Fedora infrastructure people have HiperKitty RPMs, but I've been
thrashing Google up and down and haven't been able to find RPMs for Mailman
3. Does any one know if they exist? I'd like to give it a try with a very
low traffic list server I have, but I'm growing older => lazier ;) :) and a
seldom compile anymore.

Thanks!

-- 
Victoriano Giralt                             Central ICT Services
Systems Manager                               University of Malaga
+34952131415                                  SPAIN
==================================================================
Note: signature.asc is the electronic signature of present message
A: Yes.
> Q: Are you sure ?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20140808/e6ad4e69/attachment.sig>

From alxazevedo at gmail.com  Fri Aug  8 21:51:25 2014
From: alxazevedo at gmail.com (Alex Azevedo)
Date: Fri, 8 Aug 2014 16:51:25 -0300
Subject: [Mailman-Developers] Archives on MM3
Message-ID: <EE3EC7B5-5B83-4078-991F-F2B37E8CCF8D@gmail.com>

Hey guys,
Do we have a web interface to get list archives?
Are they available (archives) on MM3 ?


Best,


Alex Azevedo
aazevedo


From pingou at pingoured.fr  Fri Aug  8 23:40:35 2014
From: pingou at pingoured.fr (Pierre-Yves Chibon)
Date: Fri, 8 Aug 2014 23:40:35 +0200
Subject: [Mailman-Developers] Archives on MM3
In-Reply-To: <EE3EC7B5-5B83-4078-991F-F2B37E8CCF8D@gmail.com>
References: <EE3EC7B5-5B83-4078-991F-F2B37E8CCF8D@gmail.com>
Message-ID: <20140808214035.GB3134@carmine.pingoured.fr>

On Fri, Aug 08, 2014 at 04:51:25PM -0300, Alex Azevedo wrote:
> Hey guys,
> Do we have a web interface to get list archives?
> Are they available (archives) on MM3 ?


You may be interested in the HyperKitty project:
https://fedorahosted.org/hyperkitty/

Demo instance: https://lists.stg.fedoraproject.org/archives/


Pierre

From rajeevs1992 at gmail.com  Sat Aug  9 05:24:52 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Sat, 09 Aug 2014 08:54:52 +0530
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <87iom3ji4o.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <53DFD7A5.8010003@gmail.com> <53DFD839.5070903@gmail.com>
 <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp> <53E274A6.2020205@gmail.com>
 <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp> <53E3C1D2.6070404@gmail.com>
 <87k36jk39p.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAPq4ZOL5waPD-dhoGCK6Z2w7eZy-Mt9U2o2xC4NoKTUYCwo6zw@mail.gmail.com>
 <87iom3ji4o.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <53E59484.6030409@gmail.com>

Hi,


On Friday 08 August 2014 05:41 PM, Stephen J. Turnbull wrote:
>
> I still don't understand this.  You have a module whose "main
> function" would perfectly servicable as "the executable" if you unwrap
> it (delete the "def main" statement and fix indentation), and in fact
> doesn't serve any purpose other than to be imported into a generated
> script?  Seems to violate TOOWDTI to me.
>
>

Fixed that. There was another argument for setuptools called `scripts` 
which does the
required task, that is, does not require the executable to have a callable.

From stephen at xemacs.org  Sat Aug  9 10:16:40 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 09 Aug 2014 17:16:40 +0900
Subject: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
In-Reply-To: <53E59484.6030409@gmail.com>
References: <53DFD7A5.8010003@gmail.com> <53DFD839.5070903@gmail.com>
 <87y4v2jew2.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53E274A6.2020205@gmail.com>
 <87oavwke12.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53E3C1D2.6070404@gmail.com>
 <87k36jk39p.fsf@uwakimon.sk.tsukuba.ac.jp>
 <CAPq4ZOL5waPD-dhoGCK6Z2w7eZy-Mt9U2o2xC4NoKTUYCwo6zw@mail.gmail.com>
 <87iom3ji4o.fsf@uwakimon.sk.tsukuba.ac.jp>
 <53E59484.6030409@gmail.com>
Message-ID: <87egwqjcwn.fsf@uwakimon.sk.tsukuba.ac.jp>

Rajeev S writes:

 > Fixed that. There was another argument for setuptools called
 > `scripts` which does the required task, that is, does not require
 > the executable to have a callable.

Cool!


From pingou at pingoured.fr  Fri Aug  8 23:39:09 2014
From: pingou at pingoured.fr (Pierre-Yves Chibon)
Date: Fri, 8 Aug 2014 23:39:09 +0200
Subject: [Mailman-Developers] Mailman 3 RPMs anyone?
In-Reply-To: <53E51C34.8010100@uma.es>
References: <53E51C34.8010100@uma.es>
Message-ID: <20140808213909.GA3134@carmine.pingoured.fr>

On Fri, Aug 08, 2014 at 08:51:32PM +0200, Victoriano Giralt wrote:
> Hi! it's been a long time since I wrote here (12 years according to my
> archives!), but I've never stopped reading :)
> 
> I'm following with a lot of interest the progress of Mailman 3 (great job,
> BTW), kudos to all devs, including the GSoC youngsters), and I've seen that
> the Fedora infrastructure people have HiperKitty RPMs, but I've been
> thrashing Google up and down and haven't been able to find RPMs for Mailman
> 3. Does any one know if they exist? I'd like to give it a try with a very
> low traffic list server I have, but I'm growing older => lazier ;) :) and a
> seldom compile anymore.

Hi,

For future reference, you can find the repository of the Fedora infrastructure
at: http://infrastructure.fedoraproject.org/repo/ (as well as the ansible repo
which include the playbook used to deploy mailman3 and hyperkitty).
However, the mailman3 RPMs are not there, Aur?lien is hosting them at:
https://repos.fedorapeople.org/repos/abompard/hyperkitty/

The repo file Aur?lien uses for the infra is at:
http://infrastructure.fedoraproject.org/infra/ansible/roles/mailman/files/hyperkitty.Fedora.repo

Hope this helps,
Pierre
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20140808/d5705a2a/attachment-0001.sig>

From tom.browder at gmail.com  Sat Aug  9 22:17:15 2014
From: tom.browder at gmail.com (Tom Browder)
Date: Sat, 9 Aug 2014 15:17:15 -0500
Subject: [Mailman-Developers] Mailman 3 RPMs anyone?
In-Reply-To: <20140808213909.GA3134@carmine.pingoured.fr>
References: <53E51C34.8010100@uma.es>
 <20140808213909.GA3134@carmine.pingoured.fr>
Message-ID: <CAFMGiz8dY1mtxsavtaJScnfcKNshjAf7MAotOHEdnLHu5Jxs9g@mail.gmail.com>

On Fri, Aug 8, 2014 at 4:39 PM, Pierre-Yves Chibon <pingou at pingoured.fr> wrote:
> On Fri, Aug 08, 2014 at 08:51:32PM +0200, Victoriano Giralt wrote:
...
>> the Fedora infrastructure people have HiperKitty RPMs, but I've been
>> thrashing Google up and down and haven't been able to find RPMs for Mailman
...
> For future reference, you can find the repository of the Fedora infrastructure
> at: http://infrastructure.fedoraproject.org/repo/ (as well as the ansible repo
> which include the playbook used to deploy mailman3 and hyperkitty).
> However, the mailman3 RPMs are not there, Aur?lien is hosting them at:
> https://repos.fedorapeople.org/repos/abompard/hyperkitty/

Are there any deb versions floating about?

If not, has anyone tested deb packages converted from the RPMs?

Best regards,

-Tom

From rajeevs1992 at gmail.com  Sun Aug 10 09:24:25 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Sun, 10 Aug 2014 12:54:25 +0530
Subject: [Mailman-Developers] [CLI Project] Code refactored as per feedback
Message-ID: <53E71E29.8040005@gmail.com>

Hi,

As per the feedback from Steve, I have made changes to the code in 
following areas

- The get_listing method has been moved to the lib/utils and has been 
rebuilt in a class
    *independent* way, and it works as good as before.
- The connection checking has been moved to the connect function, 
without the need
   of making a database call, by checking the Mailman version using 
client.system
- The addition of CLI colors has been made more generalized by making it 
a module level
   variable, with colors stored in a separate file.
- Removed class attributes from Filter class, and changed them to arguments
- All files now have a header acknowledging the support of Google, along 
with the names and contacts
   of mentors.

Here is a link to the r70

http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/70


I will be improving the error handling, as mentioned in the comments, 
with the next revision.

From alxazevedo at gmail.com  Tue Aug 12 20:13:16 2014
From: alxazevedo at gmail.com (Alex Azevedo)
Date: Tue, 12 Aug 2014 15:13:16 -0300
Subject: [Mailman-Developers] Messages not sent out of mailman v3.0.0b4
Message-ID: <56ACFA08-CEF1-42E1-B196-DD59389CA4F5@gmail.com>

Hey guys, 
we are using mailman 3.0.0b4 and we are currently have some problems with some messages that are not being sent out of mailman. 
I would like to know if in this version we have a command to check all messages queued on mailman, and what?s the expected behavior of mailman in this case. 
I mean, we?ve restarted mailman - these messages should be sent? the queue files should be deleted after that?
I?m grep?ing and just found some entries of an specific message that i?m looking for on var/queue/pipeline/ dir. What does that means?

Thanks ,


Alex

From rajeevs1992 at gmail.com  Wed Aug 13 19:47:24 2014
From: rajeevs1992 at gmail.com (rajeevs1992 at gmail.com)
Date: Wed, 13 Aug 2014 23:17:24 +0530
Subject: [Mailman-Developers] [CLI Project] Code refactored as per
	feedback
In-Reply-To: <53E71E29.8040005@gmail.com>
References: <53E71E29.8040005@gmail.com>
Message-ID: <20140813174724.5914769.72822.77@gmail.com>

?Hi,

I have made another revision, r71,that includes the following changes

1. ? More unit tests, now the methods under user preferences are also covered by tests

2. Modified the error handling so that the error is analysed before arriving at a conclusion on what message to print

3. Added a readme file for the parsers, that lists the tokens and grammar for each command

4. More code refactored and redundant code scrubbed

Here is the link to r71

?http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/71


Sent from my BlackBerry 10 smartphone.

From barry at list.org  Fri Aug 15 02:06:18 2014
From: barry at list.org (Barry Warsaw)
Date: Thu, 14 Aug 2014 20:06:18 -0400
Subject: [Mailman-Developers] One (almost) down, one to go
Message-ID: <20140814200618.3cc50146@anarchist.localdomain>

As you know, I'm keen on porting Mailman 3 to Python 3.  I can't even start
this effort until all of our dependencies are compatible with Python 3.  We
have two big blockers, restish (which provides the framework for the REST
administrative API), and Storm (our ORM).  Development for both libraries is
meager to nonexistent, and neither have been ported to Python 3, with no known
active work in progress to do so[*].

There's good news on at least one front!  I've found a very nice REST
framework that is both under active development and is already Python 3
compatible.  It's called 'falcon':

http://falconframework.org/
http://falcon.readthedocs.org/en/latest/

I've had some spare time recently to work on porting MM3 from restish to
falcon and I've been very encouraged with the results.  I've had to make a few
minor modifications to falcon, so its public release won't work, but I'm
hopeful this pull request will be successful:

https://github.com/racker/falcon/pull/307

As I describe in the PR, there are plenty of superficial API differences
between restish and falcon, but they are close enough that porting was a
breeze.  The big thing missing is restish-ish @child path segment traversal,
but with the above branch, I was able to implement the most important bits of
that in a subclass.  This means I was able to preserve the essential code of
MM3's REST implementation, adjust for the cosmetic differences, and substitute
falcon for restish *with no changes to the public MM3 administrative API*.
This last bit is crucial - neither mailman.client nor any other client of the
MM3 API will have to change.  I think I was even able to preserve the body
strings of the HTTP error codes, even though I don't consider this part of the
official MM3 API.

You can play with the MM3 falcon branch here:

https://code.launchpad.net/~barry/mailman/falcon

Until and unless a version of falcon is released with my changes above, you'll
have to git clone my falcon branch and install it into your virtualenv in
order to use the MM3 branch.  I found it a little tricky to get that working
(due to some weird dependencies on specific versions of the 'six' library),
but it's certainly doable because the full MM3 test suite passes.

That's it for now.  I won't merge the falcon branch into MM3 trunk, at least
until my PR has been merged, and I'll urge the falcon maintainer to release a
new version on PyPI to make it even easier to use.

Now, about that SQLAlchemy port... :)

Cheers,
-Barry

[*] I and others have tried to port restish.  I've failed at least twice. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20140814/75bf7df0/attachment.sig>

From rajeevs1992 at gmail.com  Sun Aug 17 12:03:09 2014
From: rajeevs1992 at gmail.com (Rajeev S)
Date: Sun, 17 Aug 2014 15:33:09 +0530
Subject: [Mailman-Developers] [CLI Project] Enhanced documentation to bring
	in Sphinx Compatibility
Message-ID: <53F07DDD.1030902@gmail.com>

Hi,

I would like to add one final revision before the firm pencil down date 
(18/08/2014).

The r72 consists largely of the documentation enhancements for the 
mailman CLI.

More documentation has been added and all the docs have been modified to 
make docs
sphinx compatible.The docs have been restructured and reorganized so 
that they build up
cleanly.

Here is a link to r72

http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/72



From barry at list.org  Tue Aug 19 20:58:28 2014
From: barry at list.org (Barry Warsaw)
Date: Tue, 19 Aug 2014 14:58:28 -0400
Subject: [Mailman-Developers] Messages not sent out of mailman v3.0.0b4
In-Reply-To: <56ACFA08-CEF1-42E1-B196-DD59389CA4F5@gmail.com>
References: <56ACFA08-CEF1-42E1-B196-DD59389CA4F5@gmail.com>
Message-ID: <20140819145828.521a004f@anarchist.wooz.org>

Apologies for the delay, I was on vacation.

On Aug 12, 2014, at 03:13 PM, Alex Azevedo wrote:

>we are using mailman 3.0.0b4 and we are currently have some problems with
>some messages that are not being sent out of mailman.

There should be artifacts in both the Mailman logs and in your MTA logs.

>I would like to know if in this version we have a command to check all
>messages queued on mailman, and what?s the expected behavior of mailman in
>this case.

You can just ls your <root>/var/queue directories to see if any files have
gotten stuck.  If you see anything in shunt it means Mailman hit an error
during the processing of this message, and there should definitely be log
entries that provide more detail.

Once you have a specific queue file you want to inspect, use
`mailman qfile <path>` to dump the pickles contained in the file.  One pickle
will be the message metadata dictionary and the other will be the message
object.

>I mean, we?ve restarted mailman - these messages should be sent?  the queue
>files should be deleted after that?  I?m grep?ing and just found some entries
>of an specific message that i?m looking for on var/queue/pipeline/ dir. What
>does that means?

It means the pipeline runner isn't processing those messages.  `pipeline` is
the queue runner that takes messages which have been accepted for posting to
the mailing list, and prepares them for being sent.  It runs all the handlers
defined in the mailing list's `posting_pipeline` handler list (unless it's
destined for the list owners, in which case it runs the `owner_pipeline` list
of handlers.

One of those handlers should be `to-outgoing` which copies the message to
var/queue/out.  From there, the outgoing runner dequeues them and passes them
off to the MTA for final delivery.

Use ps to see if your pipeline runner is running or not.

Cheers,
-Barry

From stephen at xemacs.org  Thu Aug 21 03:58:12 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 21 Aug 2014 10:58:12 +0900
Subject: [Mailman-Developers] [Soc2014-mentors] Students whose evals are not
	yet completed
In-Reply-To: <CAKhpPjq4Uj1E2gOHLc9pJre1Yk-zfc98W8bkCN2EC3WbA2qemA@mail.gmail.com>
References: <CAKhpPjq4Uj1E2gOHLc9pJre1Yk-zfc98W8bkCN2EC3WbA2qemA@mail.gmail.com>
Message-ID: <87lhqieh8r.fsf@uwakimon.sk.tsukuba.ac.jp>

Terri Oda writes:

 > We have 11 students who don't yet have evals in melange:

None from Mailman!  Yay, Mailman devs, you rock!


From barry at list.org  Tue Aug 26 23:59:36 2014
From: barry at list.org (Barry Warsaw)
Date: Tue, 26 Aug 2014 14:59:36 -0700
Subject: [Mailman-Developers] Proposed incompatible changes to the REST API
Message-ID: <20140826145936.6f694c71@anarchist>

I'm considering making two small incompatible changes to the JSON
representation of list requests in the REST API.  Here's what you currently
get (from rest/docs/moderation.rst) for a held subscription request:

    >>> dump_json('http://localhost:9001/3.0/lists/ant at example.com/requests/1')
    address: anne at example.com
    delivery_mode: regular
    display_name: Anne Person
    http_etag: "..."
    language: en
    password: password
    request_id: 1
    type: subscription
    when: 2005-08-01T07:49:23

I want to change the 'address' key to 'email' and remove the 'password' key,
e.g.:

    >>> dump_json('http://localhost:9001/3.0/lists/ant at example.com/requests/1')
    delivery_mode: regular
    display_name: Anne Person
    email: anne at example.com
    http_etag: "..."
    language: en
    request_id: 1
    type: subscription
    when: 2005-08-01T07:49:23

Unsubscription requests would just rename 'address' to 'email' (there is no
'password' key).  E.g. from:

    >>> dump_json('http://localhost:9001/3.0/lists/ant at example.com/requests/2')
    address: bart at example.com
    http_etag: "..."
    request_id: 2
    type: unsubscription

to:

    >>> dump_json('http://localhost:9001/3.0/lists/ant at example.com/requests/2')
    email: bart at example.com
    http_etag: "..."
    request_id: 2
    type: unsubscription

I could (mostly) keep backward compatibility by just adding the 'email' key
and keeping the 'address' key for now.  The 'password' key is trickier because
a subscription request's password is internally and randomly generated anyway,
and I am going to remove this.  I could keep 'password' with either the empty
string or some random garbage.

I'd like to just get rid of these and break compatibility, but if it would
cause pain to Postorius or other tools, I can deprecate the old names and
remove them in the future.

Let me know what you think.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20140826/4eeb07a7/attachment.sig>

From stephen at xemacs.org  Wed Aug 27 03:10:21 2014
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 27 Aug 2014 10:10:21 +0900
Subject: [Mailman-Developers] Proposed incompatible changes to the REST API
In-Reply-To: <20140826145936.6f694c71@anarchist>
References: <20140826145936.6f694c71@anarchist>
Message-ID: <87lhqabuv6.fsf@uwakimon.sk.tsukuba.ac.jp>

Barry Warsaw writes:

 > I want to change the 'address' key to 'email' and remove the 'password' key,
 > e.g.:

+1 on the change itself, but unfortunately I can't comment on issues
with related software.


From flo.fuchs at gmail.com  Wed Aug 27 14:52:26 2014
From: flo.fuchs at gmail.com (Florian Fuchs)
Date: Wed, 27 Aug 2014 14:52:26 +0200
Subject: [Mailman-Developers] Proposed incompatible changes to the REST
 API
In-Reply-To: <20140826145936.6f694c71@anarchist>
References: <20140826145936.6f694c71@anarchist>
Message-ID: <53FDD48A.4070605@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/26/2014 11:59 PM, Barry Warsaw wrote:
> I'm considering making two small incompatible changes to the JSON 
> representation of list requests in the REST API.  Here's what you
> currently get (from rest/docs/moderation.rst) for a held
> subscription request:
> 
>>>> dump_json('http://localhost:9001/3.0/lists/ant at example.com/requests/1')
>
>>>> 
address: anne at example.com
> delivery_mode: regular display_name: Anne Person http_etag: "..." 
> language: en password: password request_id: 1 type: subscription 
> when: 2005-08-01T07:49:23
> 
> I want to change the 'address' key to 'email' and remove the
> 'password' key, e.g.:

[...]

> I'd like to just get rid of these and break compatibility, but if
> it would cause pain to Postorius or other tools, I can deprecate
> the old names and remove them in the future.
> 
> Let me know what you think.

We're still in beta, so I think breaking backwards compatibility is
justifiable (we should probably coordinate the release of the affected
packages though).

If we want to make our lives a little easier we could keep the
"address" and "password" properties as proxy attributes in
mailman.client to minimize the risk of things breaking. At least for a
while.

In the future (once we're out of beta) we could mabye just bump up the
API version number in cases like that. BTW: Should the API version nr
always correspond with the core's version number? Like core version
3.0.12 => "http://localhost:8001/3.0"?

Florian





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJT/dSKAAoJEEceGbPdavl7lHUH/0eLV1tzfogv3MojR2TnK5DF
QS4WlJLU8s+vAZQECjrRKr5kCsiruOteVG3Hm8Ts9HEiMrq4pmjvOKc/oCl3q7C2
Hgo30mm/BCW2ZD4TQ5CCz5Q4eMV5vz01f09YS8alQx57reOx6GqSgcpTJKgjVJz4
AgGBqsDH9fkf8IGRIpoqnC4qwH4W6mofITKXLVDvAv4jHnmQv/VqMn+LN48BysI+
ij/0iH7qadTPlUfvLqv8JMNBzPBgxpEEkyVFVTQcggiwRbXTZDq8IMTBZY5E2hp5
5x4WBiNGdCJp3XwVYfmTC0/VwyM6WXbYTWDkuLhhM6iczBzdpWc+EjWNyeVtKLk=
=uUdq
-----END PGP SIGNATURE-----

From barry at list.org  Sat Aug 30 19:03:04 2014
From: barry at list.org (Barry Warsaw)
Date: Sat, 30 Aug 2014 10:03:04 -0700
Subject: [Mailman-Developers] Proposed incompatible changes to the REST
 API
In-Reply-To: <53FDD48A.4070605@gmail.com>
References: <20140826145936.6f694c71@anarchist>
	<53FDD48A.4070605@gmail.com>
Message-ID: <20140830100304.482a914b@anarchist>

On Aug 27, 2014, at 02:52 PM, Florian Fuchs wrote:

>We're still in beta, so I think breaking backwards compatibility is
>justifiable (we should probably coordinate the release of the affected
>packages though).

Cool, and yes, definitely.

>If we want to make our lives a little easier we could keep the
>"address" and "password" properties as proxy attributes in
>mailman.client to minimize the risk of things breaking. At least for a
>while.

That sounds reasonable.

>In the future (once we're out of beta) we could mabye just bump up the
>API version number in cases like that. BTW: Should the API version nr
>always correspond with the core's version number? Like core version
>3.0.12 => "http://localhost:8001/3.0"?

That was my original plan.  It means that within beta releases, the API would
be free to change (I'm not sure /3.0.12b1 would be worth it).  TBH I haven't
actually tried to see what it would mean to rev the API version path
component.  Maybe it could insert a flag on the request that end-points could
refer to if they wanted emit some different JSON, or some responder along the
path could dispatch to a different end-point if needed.  In theory <wink>, it
seems quite doable.

I'm really hoping the falcon guys will accept my patch, or at least work with
us to get restish-style dispatch working.  I *really* want to switch to
falcon.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20140830/8decc824/attachment.sig>