Re: [Mailman-Developers] GSoC Updates

[Richard Wackerbarth]

Abhilash,

I see no reason to have more that one keyring for public keys and another for 
the private ones.
In both cases, those key rings are a flat table indexed by the Key_id. It 
doesn't matter if the "owner" of the key is a list or a subscriber (or any 
other user) As for user keys, I think that they should be treated as a 
ManyToMany relation between the public keys and either the lists or users or, 
perhaps the subscriptions, in a manner similar to the way that Email addresses 
are associated with a user.

Wacky

On Aug 13, 2013, at 9:46 AM, Abhilash Raj  wrote:

> Hi all,
> 
> After midterm evaluations I have been working on signing the message
> using one the keys associated with the list, now since `python-gnupg`
> does not allow selecting keys with key credentials( like address or
> list-name name) so we need key_id. As barry suggested we can create a
> mapping of address to key_ids and store in a seperate table.
> 
> I was of the opinion that we need key_ids only for signing the content
> and hence need to select only list's keys and not user, so can we add a
> new column `key_id` to the existing list table? So that the key_id is
> easily accessible as a list parameter and can be easily updated. One
> point in this would be should we allow more than one key associated with
> a user( or address? ).
> Any comments on this? (barry?)
> 
> Also I understand that keeping key safe is one of the important tasks
> but for the time-being I am simply adding the public and secret keyrings
> in "VAR_DIR/gpg/", all the list's private keys are in `secring.gpg` and
> all the list's public keys are in `pubring.gpg` and all the user's
> public keys are in `userring.gpg`. It will be changed to keep the secret
> keys at a more safer location.
> 
> ---
> Abhilash Raj
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Systers VM for Mailman Development

[Richard Wackerbarth]

Hi,

You have provided me with EXACTLY the information that I requested.

To operate in this mode, I recommend the following:
1) Read enough about Vagrant to be able to "freeze" an image of the VM and use 
that as a base for your actual work.
That way, you can work through the initial setup of your own customized 
installation and freeze the result, That way you won't need to repeat those 
steps every time you want to make a new VM. Then, by working in an expendable 
copy of the VM, when you "mess up" (and you will :) ), you can just toss it 
away (vagrant destroy) and start over with a clean copy.

2) Whether you are working in a VM, or directly on your host machine, I 
strongly recommend the use of virtualenv and virtualenvwrapper. (I like the 
added functions of the wrapper. But the important concept is the use of the 
virtual environments)
 Virtual environments are like a "poor man's" virtual machine but they don't 
encounter the overhead of a virtual machine. They allow you to have independent 
sets of python and python libraries installed. Thus one program can use a 
different version of a library without affecting other programs.

In my setup, I use a separate virtual environment to represent each logical 
machine that runs a part of the mailman system.
Thus my mail handler (the "core" part of mailman) is in a separate virtual 
environment from the web server (postorius).

3) When it comes to development, the various python modules can be divided into 
three groups.
  a) The code that you are developing
  b) Other code that is under development but for which you want to use a 
pre-release version. (or any "source" distribution)
  c) Additional library functions upon which those parts depend.

For the vagrant virtual machine organization that you will be using:
Place the (c) routines in /vagrant and keep them under your SCM (version 
control).
You can have the (b) routines in the home directory on the virtual machine.
The (a) routines will be loaded into the site-packages for the individual 
virtual environments as a part of the installation process.

If you follow this layout, it will be easy to replace any of the various 
components whenever you desire.

Since we are new to working with Vagrant, a setup for the mailman project such 
as I describe is still a "work-in-progress".
Expect some revisions during the summer. However, they should not have any 
negative impact on your work because all of your code will be stored under the 
/vagrant mount point and can be moved readily from one virtual machine 
configuration to the next.

Now, for your code, I recommend that you start by having a separate folder for 
each of the virtual environments.
In my current setup, I have two virtual environments "VE-mailman" and 
"VE-webserver".
In your source, you can have:
/vagrant/webserver/my_django_app1/
/vagrant/webserver/my_django_app2/
/vagrant/webserver/my_website/
/vagrant/mailman/some_addition_to_mm-core/

Of course, depending on just what your project requires, you may not need all 
of these parts.

Eventually, I would expect to see a setup script that is able to use this 
layout to automate the building of a suggested installation script.

I hope that this helps.

Feel free to ask questions and make suggestions to improve this setup.

Richard

On Jun 15, 2013, at 10:44 PM, Julia Proft  wrote:

> Hi Richard,

> this is my first time using virtual machines in development, and I'm figuring 
> it out as I go! Right now, my game plan is to edit on my Windows host, and 
> I'll keep those files in a shared folder that is accessible through the VM... 
> then I can execute the files on the VM.

> Best,
> Julia

> On Sat, Jun 15, 2013 at 3:35 PM, Richard Wackerbarth  
> wrote:
> Hi, Julia.
> 
> I'm Richard "Wacky" Wackerbarth, one of the Mailman developers and a Mentor 
> for GSoC.
> 
> I notice that, in a discussion on the systems-dev mailing list, you indicated 
> that your host machine is running "Windows 7".  Since that is one of the 
> least "Unix friendly" environments, I was wondering just how you utilize the 
> Virtual Machine images in your development cycle.
> 
> It appears that the machines are set up to be "an appliance" (which is great 
> if all you want to do is deploy it). However, using ssh to communicate in a 
> terminal window isn't very friendly for developers.
> 
> So I'm wondering just where you store your code that is under development, 
> how do you edit it, and on what host you execute it?

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC Project Discussion

[Richard Wackerbarth]

OK. Then a "roster" represents the distribution list for a "feed" of outgoing 
messages.
The "mailinglist" represents the reception point(s) for the incoming messages 
and the directives for handling the processing of those messages.

The thing that hasn't been addressed is how an individual recipient can affect 
the processing of messages that are processed while he is a member of a roster.

In particular, how do the "user settings" come into play?  Presumedly, a user 
can have different settings for each list to which he is subscribed.

What, if any, individual settings apply to moderator feeds? Are these different 
from those which apply to the feed that the individual receives as a member of 
the list?

On May 30, 2013, at 6:07 PM, Barry Warsaw  wrote:

> On May 17, 2013, at 04:58 PM, Richard Wackerbarth wrote:
> 
>> Would it be easier if we just treated owners and moderators as a couple of
>> additional mailing lists.
>> 
>> In other words, for list x...@example.com, we also have virtual lists
>> @example.com and @example.com Where the list
>> names are accessible only from within MM.
>> 
>> Thus a moderator would be subscribed to the  list and that
>> subscription handled just as any other subscription would be handled.
> 
> This is an interesting question, but let me rephrase it into MM3 terminology
> to see what we can coax out.
> 
> MM3 has this notion of "rosters", and they are a fundamental object in the
> system, as described by the IRoster interface.  Through a roster, you can get
> at the IMembers, IUsers, and IAddresses which are contained in the roster.
> You can also look up an IMember from a given email address; if it's in the
> roster then you get back the matching IMember, otherwise you get None.
> 
> Mailing lists point to a bunch of rosters, and this is in fact how the
> subscriber information is accessed.  A mailing list will have:
> 
> * an owners roster
> * a moderators roster
> * an administrators roster (all owners + all moderators)
> * a members roster
> * a roster of regular delivery members
> * a roster of digest delivery members
> * a roster of subscribers (all regular + all digest)
> * a roster of "non-members"
> 
> So, when we want to send a message of a post held for moderator approval, we
> send that message to every IMember in the administrators roster.
> 
> Here's where it gets interesting.  Rosters are not modeled as rows in a table,
> they are modeled as queries.  This is cool because you can actually compose
> rosters, or pull their information from any source, including those external
> to the core.
> 
> One of the use cases for rosters that I've always had in mind are a better way
> to do MM2-style umbrella lists.  Let's say you have one mailing list for all
> of your band's New York fans, and another for all of your band's San
> Francisco fans.  It should be very easy to compose a parent (i.e. umbrella)
> list which had a roster combining the New York and San Francisco rosters, and
> it is this roster that you would deliver to when your new tour was starting.
> 
> Another use case: say a site is doing maintenance and they want to inform
> every subscriber on the system that it will be unavailable for a while.  You
> could easily compose a roster that included every registered (and validated)
> email to every mailing list, and then you'd send a message to that roster.
> 
> I think this same kind of arrangement would work for some of the things that
> dlists wants to do, or topics, etc. and I'm sure you can come up with a
> zillion other use cases.
> 
> So, in this model, what is "a mailing list"?  It's really all the
> configuration stuff *around* rosters, such as how you send a message to that
> roster from outside the system, what gets stuffed into Subject headers, and
> message footers, how do posted messages get transformed on the way to the
> roster membership, and who gets to send messages to them.
> 
> I think this isn't far from what you're asking in your original question, and
> there's much to explore here.  Whether the full power of this can be or should
> be exposed to the web ui, or the mail boundary, is much fuzzier in my mind.
> But I can clearly see how a determined developer could make this work pretty
> easily.
> 
> -Barry

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC Project Discussion

[Richard Wackerbarth]

Varun,

It is easy to say "He will receive an email about the tasks done in his 
absence". However, how do you propose to compose that email?
Where and how is the information used to construct the email stored while the 
moderator is on vacation. If on a queue, which queue? ... etc.

You seem to imply that each individual has a ToDo list of tasks. If that is the 
case, in the normal course of business, how will you handle the situation when 
there are two or more moderators and one of them processes a request.

Richard

On May 20, 2013, at 1:01 AM, varun sharma  wrote:

> Hi Steve,
> I think it will be a good idea to provide an option of digests, as the case 
> you have mentioned may occur in a real situation.
> 
> Hi Richard,
> Lets take an example of a moderator of some mailing list:
> 
> ==Before going on vacaton==
> 1. If someone sends a "new user" request, the moderator will receive an email 
> in real time about request.
> 2. The task will be added to his and other moderators' ToDo list.
> 
> ==During Vacation==
> 1. If someone sends a "new user" request, the moderator "on vacation" will 
> NOT receive any email about pending "add user" request.
> 2. The task will be added to his and other moderators' ToDo list.
> 
> ==After Vacation==
> 1. He will receive all the emails as he was receiving before going on 
> vacation.
> 2. The pending tasks will show up in his ToDo queue
> 3. He will receive an email about the tasks done in his absence
> 4. He will receive email about pending tasks that were added to his ToDo list 
> and are still pending.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC Project Discussion

[Richard Wackerbarth]

Varun,

Perhaps I did miss-attribute the material. Thank you for pointing it out. I 
offer my apologies for doing so. Sometimes the "quote levels" get confused and 
it is not easy to tell which author provided some particular text.

Since you appear to be the one responsible for the suggested behavior, would 
you please address the concerns that I raised about it.

In particular, consider what mechanisms would be needed to handle your item 2 
below (Knowing changes ...)
What if there are multiple moderators who go on overlapping vacations?

Richard

On May 19, 2013, at 11:38 AM, varun sharma  wrote:

> Hi Richard,
> I think you have misunderstood my paragraph to be barry's. I was
> suggesting the adding up of pending tasks of moderators and list
> owners to their "ToDo" list during their vacation period with
> suspension of email.
> The phrase which you have mentioned, might be confusing. But actually
> i was talking about two different operations.
> 1. The mail delivery will be stopped for moderators as well as list
> owners. So the moderators should also not receive any "add request
> pending" email during the vacation period.The todo queue will remain
> updated.
> 2. The second thing is some moderators might be interested in knowing
> the administrative changes done in their absence. So they should
> receive a summary of the tasks done(eg. users added) in their absence
> once they come back from vacation.This was what i was talking about in
> that paragraph.
> 
> On 5/19/13, Richard Wackerbarth  wrote:
>> On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw  wrote:
>>> 
>>>> On May 13, 2013, at 10:52 PM, varun sharma wrote:
>>>> 
>>>> Question: Should you be able to add a vacation stop to moderator or
>>>> owner
>>>> emails?
>>> 
>>> I think the owner or moderators also should be allowed to use the in
>>> vacation suspension of mails from the mailing lists they moderate or own,
>>> given all the administrative tasks that need their attention must be
>>> added
>>> to their ToDo queue.
>>> eg:
>>> Lets say there is a mailing list that requires moderator's approval for
>>> any
>>> new user to join. If one of the moderator has set  "on vacation" for his
>>> account, then he should only get "pending approval request"  in his ToDo
>>> task list. If some other moderator responds to that request, then it will
>>> be automatically removed from the ToDo list of all the moderators,
>>> including the one "on the vacation" and the moderator "on vacation" will
>>> never know if there was any request.
>>> 
>>> Also there can be email alerts as soon as some task is added to the ToDo
>>> list but if the user is "on vacation" then he will not receive any of
>>> these
>>> emails until he disables his "on vacation" flag. All the pending ToDo
>>> tasks/(tasks done in his absence) may be emailed him at once when he
>>> comes
>>> back from the vacation.
>> 
>> Barry,
>> You have used some phrases that cause me to infer that the -core would have
>> to keep extensive information about moderation requests.
>> 
>> For example: "(tasks done in his absence) may be emailed him at once when he
>> comes back from the vacation."
>> I hope that you meant "tasks NOT done". Otherwise, someone would have to
>> maintain a history of the tasks. (Although such an archive would appear to
>> be a task more appropriate for the KittyStore and HyperKitty retrieval
>> mechanisms.
>> 
>> Now, since "-core" maintains the queue of pending tasks and is also the
>> agent that sends out emails, do you propose the add an "on demand" type of
>> "digest" for the moderation queue?
>> We might think of this as a rendering of the current task queue in an
>> RFC-822-styled format analogous to the REST request that is delivered in a
>> JSON based format. Presumedly, since this is a "push" notification, the
>> "return from vacation" process could trigger this request.
>> 
>> Richard
>> 
>> 

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC Project Discussion

[Richard Wackerbarth]

On Sat, May 18, 2013 at 1:46 AM, Barry Warsaw  wrote:
> 
>> On May 13, 2013, at 10:52 PM, varun sharma wrote:
>> 
>> Question: Should you be able to add a vacation stop to moderator or owner
>> emails?
> 
> I think the owner or moderators also should be allowed to use the in
> vacation suspension of mails from the mailing lists they moderate or own,
> given all the administrative tasks that need their attention must be added
> to their ToDo queue.
> eg:
> Lets say there is a mailing list that requires moderator's approval for any
> new user to join. If one of the moderator has set  "on vacation" for his
> account, then he should only get "pending approval request"  in his ToDo
> task list. If some other moderator responds to that request, then it will
> be automatically removed from the ToDo list of all the moderators,
> including the one "on the vacation" and the moderator "on vacation" will
> never know if there was any request.
> 
> Also there can be email alerts as soon as some task is added to the ToDo
> list but if the user is "on vacation" then he will not receive any of these
> emails until he disables his "on vacation" flag. All the pending ToDo
> tasks/(tasks done in his absence) may be emailed him at once when he comes
> back from the vacation.

Barry,
You have used some phrases that cause me to infer that the -core would have to 
keep extensive information about moderation requests.

For example: "(tasks done in his absence) may be emailed him at once when he 
comes back from the vacation."
I hope that you meant "tasks NOT done". Otherwise, someone would have to 
maintain a history of the tasks. (Although such an archive would appear to be a 
task more appropriate for the KittyStore and HyperKitty retrieval mechanisms.

Now, since "-core" maintains the queue of pending tasks and is also the agent 
that sends out emails, do you propose the add an "on demand" type of "digest" 
for the moderation queue?
We might think of this as a rendering of the current task queue in an 
RFC-822-styled format analogous to the REST request that is delivered in a JSON 
based format. Presumedly, since this is a "push" notification, the "return from 
vacation" process could trigger this request.

Richard

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC Project Discussion

[Richard Wackerbarth]

On May 18, 2013, at 12:29 AM, "Stephen J. Turnbull"  wrote:
> I don't contest that there are strong similarities between a "list of
> moderators" and a "mailing list of subscribers".  What I'm saying is
> that they're not the same, there are several variations on the theme,
> and we must strongly consider deriving them from a more general type.

>>> I don't think this will fit users' models of the moderator and owner
>>> roles.  Mailing lists have moderators, not an auto-generated
>>> associated mailing list containing only the moderators.
>> 
>> That all depends on how you present it, not on how you implement
>> it.  IIRC, the list of moderators is a roster, just like the
>> subscribers.  A different template can make two rosters appear to
>> be quite different.
> 
> The developers are users too, though.  I think the implementation, not
> just the presentation, should correspond to our notions of "what
> things are."

Yes. But, as you note, "what things are" can be viewed as two cases of a 
"distribution list".
And that conceptual object can include more of the characteristics of a mailing 
list than just "a roster".

It is often useful to look for similarities rather than differences.

> Steve

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC Project Discussion

[Richard Wackerbarth]

I'm not convinced that it would require all of the items that you enumerate.

First, you have to look at how messages might get to the list.  Since I 
specified that the list was a virtual list (unreachable), the only source of 
messages would be from the internal queue handlers. Thus they would bypass spam 
filters, etc. and go directly to the distribution queue.

True, we would have to make the lists "hidden" to normal users. But this is not 
a significant change in list handling. We already have the requirement to hide 
other lists.

As for "empty lists", that is really a function of how empty lists are handled 
in general. Perhaps a "divert if empty" policy should be available for all 
lists. And, at the top of the chain we assure a "last desperation" address 
because no-one has the right to delete THAT one entry.

I agree that it might be messier. But it still might be cleaner if you want the 
moderators, etc. to have all of the "subscription options"

On May 17, 2013, at 9:38 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> Would it be easier if we just treated owners and moderators as a
>> couple of additional mailing lists?
> 
> That would require additional, complex attributes that aren't
> appropriate for most lists to be given to all lists.  They'd have to
> have a .virtual_list_for attribute, for example.  If non-null, you
> can't post to it.  (Or can you?  Messy.)  The owner list would have to
> have a .cant_delete_last_subscriber attribute.  These lists need to be
> suppressed when working with the set of "real" mailing lists.  These
> lists should be exempted from spam-checking since only Mailman core
> ever posts to them.  (Or should they?  See above.)  I think this all
> violates duck-typing and gets messier, not easier.
> 
>> Thus a moderator would be subscribed to the  list
>> and that subscription handled just as any other subscription would
>> be handled.
> 
> I don't think this will fit users' models of the moderator and owner
> roles.  Mailing lists have moderators, not an auto-generated
> associated mailing list containing only the moderators.

That all depends on how you present it, not on how you implement it.  IIRC, the 
list of moderators is a roster, just like the subscribers.  A different 
template can make two rosters appear to be quite different.

> My $0.02.

2 yen :)

> Steve

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC Project Discussion

[Richard Wackerbarth]

On May 17, 2013, at 3:16 PM, Barry Warsaw  wrote:
> Question: Should you be able to add a vacation stop to moderator or owner 
> emails?

Would it be easier if we just treated owners and moderators as a couple of 
additional mailing lists.

In other words, for list x...@example.com,
we also have virtual lists @example.com and 
@example.com
Where the list names are accessible only from within MM.

Thus a moderator would be subscribed to the  list and that 
subscription handled just as any other subscription would be handled.


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface.

[Richard Wackerbarth]

Yes, I, too, would leave it to Peter.  And I am not suggesting that he attempt 
to make any complete "inventory".
But I don't see how you can possibly "decide requirements" without taking them 
into consideration.

On May 9, 2013, at 1:58 PM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:
> 
>> However, we need to keep the "level of integration" issue open
>> until someone (presumedly the student) completes an inventory of
>> reasonable possibilities.
> 
> I would like to leave that up to Peter.  (We should avoid burdening
> the students with chores like inventorying possibilities, unless it
> helps them decide requirements, design the application, and code the
> implementation.)
> 
> BTW http://tools.ietf.org/html/rfc6068 describes the mailto: URI.
> It's remarkably flexible, although the body does present some special
> problems.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface.

[Richard Wackerbarth]

On May 9, 2013, at 12:06 PM, "Stephen J. Turnbull"  wrote:

> Barry Warsaw writes:
>> On May 08, 2013, at 10:31 AM, Richard Wackerbarth wrote:
>> 
>>> I agree with Steve. One of the advantages of Django is its "mix and match"
>>> capability.  Actually, I see two possible apps. One would integrate with
>>> HK. The other would be simpler, just providing a posting mechanism that
>>> provides authenticated message sender.
> 
> I'm not sure what you're proposing in terms of "integration".  The way
> I see it, is HyperKitty or any other app could provide links which
> could invoke the web posting app or the user's MUA.  The web posting
> app would have an URL like
> 
>http://list.example.com/HyperKitty/post/MSG_INIT_INFO
> 
> where MSG_INIT_INFO would have the same format as a mailto: URL.  So,
> HyperKitty would be in a good position to generate References and so
> on for any message in the archive, but other apps would be able to
> generate their own special messages.  Eg, Roundup could put issue refs
> in posting URLs it puts in issue pages.

Steve, what you are describing is a possible form of the "integration" that I 
suggest. However, there may be much more information that should be included. 
As an example, one might want some kind of automatic "seeding" of a part of the 
message based on the content of the message referenced Another possibility 
would be a way to avoid extending some of the links from a multi-linked 
message. I don't know enough about the details avail to attempt to provide a 
more precise description. However, we need to keep the "level of integration" 
issue open until someone (presumedly the student) completes an inventory of 
reasonable possibilities.

I was contrasting that situation with another which simply provides an 
authenticated submission of a message.

My point is that these two (and others) need not be mutually exclusive.


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC discussion

[Richard Wackerbarth]

On May 8, 2013, at 5:33 PM, Florian Fuchs  wrote:

> 2013/5/7 Manish Gill :
>> Hey guys. This is in response to Richard's email for project discussions.
>> 
>> Richard and I have been having discussion regarding how to proceed with the
>> project and he has been very helpful in getting me started with the project.
>> 
>> Right now, I'm focusing on the internal data representation of various
>> Resources in the system and how they might translate on an API level. So,
>> for example, in trying to expose `MailingList` objects, as of now, there is 
>> no
>> way to post messages to a list externally.
> 
> I don't know if posting messages through the API is a priority. I'd
> suggest to start with the more fundamental functionality, like
> creating domains/lists, list configuration, subscribing and
> unsubscribing, adding owners and moderators, moderating subscriptions
> and messages.

I agree. I have ask that he organize the set of objects that he wishes to 
present and the interactions between them.
For example, "persons", "mailinglists", "configuration parameters", and actions 
such as "subscribe".

"posting a message" might be an action that gets included on the list. However, 
it first assumes that there is some "message" object and, additionally, some 
way to have received it. Only when we have established the context will we be 
able to determine what capability is already present and what might be needed 
if we were to add or change it.

But, the same can be said for "subscribe".  Therefore, at this time, I place 
both of them in the category of "possible interactions" until we have a more 
complete statement of the system model.

> Regarding owners and moderators: It's true that the core's REST API
> does not expose them as single models, but as membership records with
> a 'role' attribute.

How the -core, or postorius, presents something is not the only factor.
It is perfectly permissible to have alternate presentations of the same data.

The only requirement is that there be a translation to and from the 
presentation representation and the storage representation.

> In Postorius, the permissions that are granted to each of these roles
> are static, for example a moderator can moderate messages as well as
> subscription requests, but it's currently not possible to create
> groups of moderators that can only moderate messages *or*
> subscriptions. In theory it would be possible to ignore the roles
> given by the core and grant more fine-grained permissions to separate
> groups or users. But (at least for now) Postorius does not do that for
> various reasons.

The "role" model for authorization is quite adequate, even desirable, in a 
historical sense.
However, it should not be the responsibility of the REST interface to DETERMINE 
the policy.
Rather, it should IMPLEMENT a policy, whatever it is, that the system 
installation provides.

Further, there are a number of ways that the policy can be presented.
We should not presuppose how it will be accomplished.

> There has been some discussion on IRC and elsewhere if the public API
> should be implemented as part of Postorius (as the project title on
> the ideas page says) or as separate app. My personal opinion is that I
> don't have a problem with any of the two options. But I *do* think
> that if we provide an "official" admin web ui and and "official"
> public facing REST API, both of them should reflect the role system
> reflected in the core and both should have the same authorization
> logic -- meaning: A list owner/moderator/member in Postorius should be
> allowed the same things as a list owner accessing the public REST API.

I agree that, unless the system is explicitly installed otherwise, it would be 
confusing if they are not the same.
However, a case can be made for the presence of both a "simplified" version of 
something (because it is adequate, and less confusing and a more powerful 
representation (for the "power user") coexisting on the same system.
The presence of the "simple" version should not dictate restrictions on every 
version

Richard
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC discussion

[Richard Wackerbarth]

On May 8, 2013, at 5:33 PM, Florian Fuchs  wrote:

> 2013/5/7 Manish Gill :
>> Hey guys. This is in response to Richard's email for project discussions.
>> 
>> Richard and I have been having discussion regarding how to proceed with the
>> project and he has been very helpful in getting me started with the project.
>> 
>> Right now, I'm focusing on the internal data representation of various
>> Resources in the system and how they might translate on an API level. So,
>> for example, in trying to expose `MailingList` objects, as of now, there is 
>> no
>> way to post messages to a list externally.
> 
> I don't know if posting messages through the API is a priority. I'd
> suggest to start with the more fundamental functionality, like
> creating domains/lists, list configuration, subscribing and
> unsubscribing, adding owners and moderators, moderating subscriptions
> and messages.

I agree. I have ask that he organize the set of objects that he wishes to 
present and the interactions between them.
For example, "persons", "mailinglists", "configuration parameters", and actions 
such as "subscribe".

"posting a message" might be an action that gets included on the list. However, 
it first assumes that there is some "message" object and, additionally, some 
way to have received it. Only when we have established the context will we be 
able to determine what capability is already present and what might be needed 
if we were to add or change it.

But, the same can be said for "subscribe".  Therefore, at this time, I place 
both of them in the category of "possible interactions" until we have a more 
complete statement of the system model.

> Regarding owners and moderators: It's true that the core's REST API
> does not expose them as single models, but as membership records with
> a 'role' attribute.

How the -core, or postorius, presents something is not the only factor.
It is perfectly permissible to have alternate presentations of the same data.

The only requirement is that there be a translation to and from the 
presentation representation and the storage representation.

> In Postorius, the permissions that are granted to each of these roles
> are static, for example a moderator can moderate messages as well as
> subscription requests, but it's currently not possible to create
> groups of moderators that can only moderate messages *or*
> subscriptions. In theory it would be possible to ignore the roles
> given by the core and grant more fine-grained permissions to separate
> groups or users. But (at least for now) Postorius does not do that for
> various reasons.

The "role" model for authorization is quite adequate, even desirable, in a 
historical sense.
However, it should not be the responsibility of the REST interface to DETERMINE 
the policy.
Rather, it should IMPLEMENT a policy, whatever it is, that the system 
installation provides.

Further, there are a number of ways that the policy can be presented.
We should not presuppose how it will be accomplished.

> There has been some discussion on IRC and elsewhere if the public API
> should be implemented as part of Postorius (as the project title on
> the ideas page says) or as separate app. My personal opinion is that I
> don't have a problem with any of the two options. But I *do* think
> that if we provide an "official" admin web ui and and "official"
> public facing REST API, both of them should reflect the role system
> reflected in the core and both should have the same authorization
> logic -- meaning: A list owner/moderator/member in Postorius should be
> allowed the same things as a list owner accessing the public REST API.

I agree that, unless the system is explicitly installed otherwise, it would be 
confusing if they are not the same.
However, a case can be made for the presence of both a "simplified" version of 
something (because it is adequate, and less confusing and a more powerful 
representation (for the "power user") coexisting on the same system.
The presence of the "simple" version should not dictate restrictions on every 
version

Richard
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC Project Discussion - Web Posting Interface.

[Richard Wackerbarth]

I agree with Steve. One of the advantages of Django is its "mix and match" 
capability.
Actually, I see two possible apps. One would integrate with HK. The other would 
be simpler, just providing a posting mechanism that provides authenticated 
message sender.

On May 8, 2013, at 10:19 AM, Stephen J. Turnbull  wrote:

> Peter Markou writes:
> 
>> Now regarding Richard's email, "GSoC Applicants". After having a
>> comprehensive examination in Hyperkitty I found that the functionality
>> for posting messages through web exists.
> 
> I think it should be split out as a separate Django app, independent
> of HyperKitty.
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoC discussion

[Richard Wackerbarth]

On May 7, 2013, at 1:13 PM, Stephen J. Turnbull  wrote:
> Manish Gill writes:
> 
>> So, for example, in trying to expose `MailingList` objects, as of
>> now, there is no way to post messages to a list externally.
> 
> Out of scope.  You could do something that would allow a quick, urgent
> message to be posted, but you are very likely to embarrass yourself,
> and us.  Eg, http://code.google.com/p/soc/issues/detail?id=1843. :-)
> 
>> Similarly, something to extend the Member model so that privileges
>> make sense on an API level - with Owners and Moderators being able
>> to perform certain actions that are not exposed to regular members,
>> etc.
> 
> I think Wacky would disagree with that strategy.  Extending the member
> model is not a maintainable strategy.  There are several alternatives
> that are more extensible.
> 
>> What will be useful to have:
>> 
>> - Methods to provide filtering based on various criteria.
> 
> Filter what?

I was comparing what a consumer of the Postorius interface might like to see 
that is not just a proxy forwarding the MM-core interface.

As an example, rather than all of the lists, just those lists for which the 
represented user is the administrator.
If the interface is not going to provide full SQL query capability, it can 
still provide some portion of the selection filtering.

>> Wacky:
>> 1. One way to look at moderators is that it is nothing more than 
>> another mailing list (with different policies about subscribing,
>> etc.)
>> 2. Another way is to consider it to be an additional roster of a 
>> different class of subscribers.
>> 3. Another way is to treat each subscription as having one or more 
>> roles.
> 
> Another way is ACLs on resources.

Here I was speaking of ways that an installation might present the information 
-- trying to show that the "storage model", whatever it happens to be, might 
not be the view that the implementor wishes to display.

I appears that my communication was not as successful as I had hoped.


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC - Seeking insight on Authenticated RESTful APIs

[Richard Wackerbarth]

On May 6, 2013, at 4:36 AM, Stephen J. Turnbull  wrote:

>> Initially , I was familiar with tastypie and I was strongly considering to
>> use Tastypie only for this project. However after some advice from Richard
>> , I am trying  to be more flexible and I am trying to evaluate both the
>> frameworks separately.
> 
> With all due respect to Richard (if that's what he advised), "being
> flexible" here is not a good reason to look at multiple frameworks.  I
> would recommend going with the framework you know.
> 
>> I am yet to figure out how to use [django-tasty-pie] with Non-ORM
>> data resources precisely how to integrate it into postorius so I
>> can serve the APIs .
> 
> This, on the other hand, is a reason to consider changing, if it's
> really unclear how to use Tasty Pie to do the job.

Let me clarify.  The flexibility that I was suggesting was that he not "marry" 
his proposal to one particular implementation (Tasty Pie vs 
django-rest-framework) until he has a better understanding of the requirements 
and capabilities.

In other words, let the evaluation of the alternatives be a part of the project 
rather than a precursor.
>From my experience, the choice is not clear-cut.

> If this is the best you can do for Tasty Pie I'd say you're pretty much 
> blocked on this route, and you should
> just switch to django-rest-framework, unless you find a clear reason to 
> prefer Tasty Pie.

Just my point.  :)
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSoc - Requirement from Mentor to complete the project

[Richard Wackerbarth]

Abhilash,
Thanks for responding promptly and publicly.

You, and the others should expect the discussions you mention without including 
them in response to my question.
The discussion with your mentor is "given" -- That's one of the main 
responsibilities of a mentor.
You may need to initiate community discussion about parts of your design to 
assure that your design meets the community expectations.

But let me take your project as an example of the kind of input that I am 
seeking.

You propose to use public key crypto in the processing stream of mail messages.
In order to do so, you will need to associate the appropriate key with the 
corresponding user.
You will also need to have some configuration parameters that describe the list 
policy and handling of the encryption.

Now, I suggest that you need, but might reasonably expect someone else to 
provide, the following:

1) A framework for storing the keys and handling the association of the key 
with a particular user.
This same framework would be used to associate other methods of identification 
and authentication with the users.
You would be expected to implement the parts that are specific to public key.

2) A mechanism to display and edit parameters that describe the list policy as 
it refers to encryption.
Again, as above, you would specify the parameters and provide the handlers that 
implement the policies, but you can expect someone else to handle the GUI 
presentation that turn them on and off, or otherwise configure them.

I won't claim that the items that I suggest above are sufficient, or perhaps 
even necessary, but they can be used as examples for the kind of input that I 
am encouraging all of the applicants to discuss.

There are other applicants who have proposed to develop, for example, GUI 
components. They should "step up" and declare that their proposed work will 
provide . Thus, we can observe that the projects 
complement each other.

I hope to see this discussion continue.

As for "mentor review" of your design.  Let me point out that you do not have 
to be accepted by GSoC in order to contribute to MM development. I know that I, 
and I believe the other mentors, as well as other members of the community, 
would be quite willing to discuss "design" with anyone who wishes to help 
improve the overall system.
That discussion can start at any time. We don't need to wait for the GSoC 
positions to be announced.

Again, thanks for your participation.

Richard


On May 5, 2013, at 7:23 AM, Abhilash Raj  wrote:
> In response to Richard's mail these are the rough bits of what I will be 
> needing from my mentor if I am selected:
> 
> 1) I need to discuss

> Abhilash Raj

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] GSoC Applicants

[Richard Wackerbarth]

Calling all GSoC applicants -- You have all looked at the current state of MM 
and made proposals to improve it. Now it is time to discuss what YOU need 
others to provide so that your contribution fits into the "whole" without your 
having to implement everything yourself. Let's discuss what you would like from 
the mentor-developers and, as a "class" how your contributions would complement 
each other.

You can start up the discussion on IRC #mailman or on this mailing list.

Let's hear from you.

Richard "Wacky" Wackerbarth
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)

[Richard Wackerbarth]

Terri,

For Systers, is it better to try to access Postorius through its REST API or by 
directly including it as a django app?

In particular, using Django 1.5 and the custom user module feature that it 
provides along with the scheme that I outlined earlier provides an easy path to 
developing and integrating features such as the essays into the user profile.
Basically, we share a common User model.  Someone can start by using the 
standard django.contrib model and ignore the Postorius specific parts.

I am willing to implement the pieces (I estimate needing only a day or two if I 
do a simple version), but I also think that it would be an appropriate task for 
one of the students.

Richard

On Apr 30, 2013, at 10:31 AM, Terri Oda  wrote:
> On 13-04-29 11:28 PM, Stephen J. Turnbull wrote:
>> Actually, there aren't any students explicitly discussing extra profile
>> information in their proposals.  They talk airily about "extended REST
>> API" or similarly generic terms.  None talk about storage or
>> representation of profile information.  (OK, it was 3am, my memory is
>> fallible.  I don't remember any, though.)
>> 
> 
> Oh!  I think I understand some of the confusion now.  I thought I'd said at 
> the beginning why I was starting this thread at all, which is primarily 
> because Systers has a student project that needs extra profile info.  There 
> are also a collection of students with minor features that would use the data 
> store that they've used to pad out projects that might otherwise be too short 
> (For example, see some of the ideas Peter Markou mentioned in his recent 
> post).  But now that you mention it, I've been talking to a lot of folk on 
> IRC and they often don't tell me if they're applying with Mailman or Systers, 
> so maybe there's more of them with Systers than with Mailman?
> 
> 
> For those not familiar, Systers runs a heavily modified version of Mailman 
> 2.1.  They'd like to switch to Mailman 3 shortly after we release Mailman 
> Suite (whenever that's going to be), but they've got a few features that 
> they'll need to either have integrated to core Mailman or maintained as 
> branches.  This year, they've got a project set up to port one of them to 
> Mailman 3/Postorius as part of preparing them for that.
> 
> The specific feature they're hoping to add this year stores essays that 
> people write when they subscribe.  It's currently done with a database 
> grafted on to Mailman 2.1 that was being used for another extended feature, 
> but obviously if we're going to mentor such a project for Mailman 3, we'd 
> like to use something at least approximating a real data store design.   The 
> problem is that the Systers mentors are mostly used to systers-mailman, based 
> on 2.1, and I'm not sure anyone will have the Mailman 3.0 knowledge to guide 
> a student through a halfway reasonable design, so I asked here in order to 
> help them out so that their student could start on the essays (likely to be 
> the easier part of her project) right at the beginning of the GSoC period.  
> If we can't come to a moderate consensus on that design, I should be telling 
> the Systers folk that this project won't be able to run this year, but I 
> honestly figured we'd have a simple design after a couple of posts... I 
> wasn't counting on aut
 hentication blowing up to a huge argument, and I don't have time for it do so 
if we want to make a good decision about this specific project.
> 
> So yeah, totally cool to be thinking about the more advanced projects in 
> general, but I started this thread due to a specific need for a "good enough 
> approximation for this Mailman suite release" version of the extra data 
> store, and I still need a consensus on that that's either implemented or 
> simple enough for a student to do in the first week of GSoC.   I think we're 
> pretty close to that point, but I'm not sure it's yet described in a way that 
> we can hand it off safely to a student and get a REST API that actually 
> meaningfully matches the discussion within a couple of days.  Probably we 
> need an actual set of doctests for the student to work against next and then 
> we'll be there.
> 
> Incidentally, I've been trying to get the students interested in this 
> particular Systers project to come to this mailing list and join in the 
> discussion, but it's become *very* intimidating to take part in this thread, 
> which is the other reason I need folk to take a step back.
> 
> Terri
> 
> 

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)

[Richard Wackerbarth]

Patrick,

This IS about GSoC. If we accept Terri's position, as stated and without 
question, then we are, de facto, eliminating some of the proposals based only 
on subject matter. The students making these proposals are doing so in good 
faith, and often based on "ideas" provided by our organization.

I consider that doing so is totally inappropriate. As I state, we need to 
maintain a structure whereby each of the proposed projects can proceed without 
being blocked by another project, but done in such a manner that they can be 
integrated into the whole as they develop into functioning code.

Richard

On Apr 30, 2013, at 5:47 AM, Patrick Ben Koetter  wrote:

> Richard,
> 
> * Richard Wackerbarth :
>> Again, we agree. (Something must be wrong :) ) I think that it is important 
>> that "we" (the senior developers and mentors) assure that we maintain a 
>> structure whereby each of the student proposals can proceed at the same time.
> 
> I believe you have been asked very politely not to continue this thread
> yesterday and give way for more pressing topics such as GSoC. Can you please
> do so?
> 
> p@rick
> 
> -- 
> [*] sys4 AG
> 
> http://sys4.de, +49 (89) 30 90 46 64
> Franziskanerstraße 15, 81669 München
> 
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
> Aufsichtsratsvorsitzender: Florian Kirstein
> 
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)

[Richard Wackerbarth]

Steve,

Again, we agree. (Something must be wrong :) ) I think that it is important 
that "we" (the senior developers and mentors) assure that we maintain a 
structure whereby each of the student proposals can proceed at the same time.

Thus, for example, someone working on the User interface can do so without 
requiring the "secure" mail features.
At the same time, we provide a place (Eg. the Credentials store) that can be 
used to hold public keys associated with individual subscribers.

Now I will admit that I haven't thought about the criteria associated with 
permitting someone to add a public key-->user association. But, within whatever 
policy is needed, we have a method to handle the storage and the framework 
within which the system can "GetUserByCredential()", etc.

Richard

On Apr 30, 2013, at 12:28 AM, Stephen J. Turnbull  wrote:

> Terri Oda writes:
> 
>> 1. I would like to remind/tell you all that FOR THIS RELEASE, we will 
>> ONLY be supporting Mozilla Persona and passwords as authentication 
>> methods.
> 
>> 3.  While I agree that thinking about these things in advance is useful, 
>> I think this discussion is starting to crowd out discussions of
>> time-sensitive things like students' GSoC applications and
>> architectural choices that directly impact how they write said
>> applications.
> 
> Hold on!  Who's "we" and what is being released?  There are at least 3
> more or less separate projects here (Mailman core, Postorius, and
> HyperKitty).  For login of the webapps Postorius and HyperKitty, I
> certainly agree that aiming releasing them simultaneously with core
> 3.0, focusing on a particular authn mechanism (and given work done at
> the sprints, it should be Persona) is appropriate.
> 
> But Mailman 3.0 is *not* the only item on the agenda here.  We have a
> pile of GSoC students who want to implement various forms of authn for
> Mailman core functionality (secure lists) and some REST API (not clear
> to me which subproject these adhere to, the core Mailman REST API or a
> new one to be provided by Postorius).  AFAICT, *Persona is not
> appropriate* for these use cases, as it implies interactive use of a
> full-featured web browser.
> 
> Are you saying that (despite our ideas page) these proposals are a
> priori nearly unacceptable?  It's also rather late in the process to
> change the rules on the students: if experience is any guide, Melange
> availability is going to start deteriorating soon.
> 
>> So... can we please backburner parts of this discussion until after
>> GSoC so that we don't make it impossible for anyone to start on any
>> project involving extra profile info? I don't want to bog down a
>> student with the need to make this choice and work with these
>> decisions at this stage.
> 
> Actually, there aren't any students explicitly discussing extra profile
> information in their proposals.  They talk airily about "extended REST
> API" or similarly generic terms.  None talk about storage or
> representation of profile information.  (OK, it was 3am, my memory is
> fallible.  I don't remember any, though.)
> 
> 
>> For the purposes of GSoC this summer:
>> 
>> Authentication for the purposes of the extra profile info data store 
>> will be provided by either Persona through the web interface or 
>> passwords.
> 
> OK.
> 
>> Yes, even internally for the REST interface: passwords+localhost
>> are good enough for Mailman Core right now, so it's good enough for
>> anything else we do short-term.
> 
> That's going to strongly bias decision-making against at least one
> REST API proposal, which was made in good faith.
> 
> It also formally seems to rule out the secure lists proposal, which
> obviously depends on an off-line non-localhost authn protocol (based
> on OpenPGP or S/MIME).  Is that your intention?
> 
> Regards,

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Steve,

In my opinion, the normal use case doesn't even need the generality of 
"domains".
Now that we are talking about only the few percent remaining installations, I 
have to seriously ask how many of those will not be handled by "power users"?

My concern is that, in your effort to "protect" the less sophisticated, you are 
excluding some very few, but extremely "powerful" users.   I share the goal of 
"world domination". I don't want to exclude anyone if we can avoid it.

Richard

On Apr 29, 2013, at 11:57 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> There are two aspects of using a "generic tree". The first is some
>> customization of the tree to fit the installation's delegation
>> model. Here, I would suggest that "sample base installations"
> 
> Once again, you're making an argument based on theory that nobody
> disagrees with, certainly not me, and not even attempting to address
> my request for use cases.
> 
> We're not making progress.  Let's just agree to disagree, and accept
> that there's a rather high probability that we can't work together.
> In commenting, I'll play the loyal opposition, and we can hope other
> developers will keep me honest.
> 
> Regards,
> Steve
> 

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] About authentication (was Re: Architecture for extra profile info)

[Richard Wackerbarth]

On Apr 29, 2013, at 3:06 PM, Terri Oda  wrote:

> 1. I would like to remind/tell you all that FOR THIS RELEASE, we will ONLY be 
> supporting Mozilla Persona and passwords as authentication methods.  This is 
> not up for discussion at this time; it's a choice we've made to in order to 
> help move the release forwards.

That doesn't bother me as long as we recognize that the list of acceptable 
methods be extensible.
In other words, adding a new method would require only the addition of the 
necessary handlers, forms, etc. and NOT require the re-engineering of the code 
that handles BrowserID or username/password.

> 2. As such, any discussion of enterprise use of google or twitter or what 
> have you is pretty much academic.   I am satisfied if our authentication plan 
> for methods other than Persona and passwords is "And then the magical python 
> gnomes associate an external account with an internal mailman account!"  (I'm 
> not being entirely facetious here; libraries such as django-social-auth are 
> likely to make this sufficiently trivial that it might as well be gnomes.)

Agreed.

> Authentication for the purposes of the extra profile info data store will be 
> provided by either Persona through the web interface or passwords.  Yes, even 
> internally for the REST interface: passwords+localhost are good enough for 
> Mailman Core right now, so it's good enough for anything else we do 
> short-term.

I'll go further than that and suggest, for the purpose of GSoC:

1) The USER module will be implemented as a Django 1.5 app.
2) In addition to a custom user model 
(https://docs.djangoproject.com/en/dev/topics/auth/customizing/#auth-custom-user),
 it will provide a Credential verification service.
The service will store the associations between users and the 
parameters used to identify them -- protocol, identifier, confirmation. If the 
credentials match, the service will return a user_identifier which will be used 
to access additional information about the user. 
3) The user_identifier will be of a form chosen by the USER module. Other 
modules (such as MM-core) may associate alternate identifiers (in their 
namespace) and set or retrieve them. When installed as a part of a MM system, 
at the installer's discretion, additional user profile information may also be 
added.

4) Both the User information and the Credential service will be exposed on a 
RESTful interface.
5) This Django app may be installed as a part of a Postorius interface or run 
as a standalone service.

In the future alternate implementations might be considered, but this will do 
for now.

It also has the advantage that multiple students can work on things affecting 
the user record without the other student's work becoming a stopping point to 
their progress.  Then, as they get them working, they can be merged into the 
postorius system.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 29, 2013, at 8:12 AM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> So you have at least three layers. Do you really think that it is
>> more difficult to implement a general recursive tree than it is to
>> implement those layers?
> 
> No.  What I think is difficult is to implement a general recursive tree
> *and* an API for expressing properties of nodes that make them
> equivalent to the specialized hierarchy *and* a usable interface for
> specifying and managing those properties by non-programmer users
> (including admins).

There are two aspects of using a "generic tree". The first is some 
customization of the tree to fit the installation's delegation model. Here, I 
would suggest that "sample base installations" be made available so that the 
installation of a workable tree structure is nothing more than copying a 
supplied configuration base. "Power users" should be able to understand the 
structure and customize it to fit their particular situation.

The other aspect is "how to display" them, particularly because of inheritance 
within the tree.
I don't see "display the tree of lists" as a problem. There are a number of 
reasonable implementations available for adoption.
IMHO, the key to displaying particular the individual parameters is to use a 
consistent presentation style and "focusing" on a particular node in the tree.

That style can be driven by css using class selectors on each individual item.

As for "domain" vs "list", I view them as just two versions of the same thing 
-- namely a node with a dictionary of properties.

By limiting access permission, even though they are present (in a virtual 
sense), and by modeling each list as having all of the properties of itself and 
the MM-domain which contains it, we can use one mechanism to handle the both 
the domain administrator and the list administrator. The only distinction is 
the point of focus.

>> Another case for generality is permissions. I don't propose to know
>> all of the parameters that will be associated with a list.
> 
> You're pushing on a string here.  I'm not opposed to generality in
> general. ;-)  What's more important to me than whether you know all of
> the parameters that will be associated with a list :-) is that I'm
> pretty sure I don't want Postorius's views to know.

Postorius need only know about those items that should be viewed or modified 
once the system is running.

>  That leads to ugly and unmaintainable code.

Or you can treat them in a generic manner, even make them "discoverable", and 
attach the appropriate ACL information.  :)
This is, in effect, the approach that django takes with its "Model" and "Admin" 
constructs.

One reason that I advocate attaching the parameters to the list-tree nodes as a 
dictionary is so that it is easy to add or delete items without having to 
change the data transfer structure.

> I also don't want users to be seeing data they don't need to see, or
> shouldn't see, and they mustn't be able to change parameters they
> shouldn't change.

Agreed. One purpose of a list hierarchy is to make it easier to specify and 
maintain these attributes.

>  These requirements can be fulfilled in a number of
> ways, including customization by extension modules.  For example,
> there could be (extensible) lists of parameters attached to each role,
> a list for each permission.
> 
> I think that's kind of fragile; better to attach an ACL to each
> permission.  (I think that's basically what you have in mind, too.)


___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 11:59 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:

> My point is that IMHO it's flexible *enough*.
> 
>> I'm advocating that we attach the roles (whatever they may be) to
>> an entire collection of lists.
> 
> I know what you're advocating, and I agree with the general theory of
> constructing for flexibility.  I just don't see a need for it.

One point that I had overlooked is that you have already acknowledged an 
additional "layer" between "domain" and "list".
So you have at least three layers. Do you really think that it is more 
difficult to implement a general recursive tree than it is to implement those 
layers?

Another case for generality is permissions. I don't propose to know all of the 
parameters that will be associated with a list. In fact, I am sure that they 
will change over time.  There has already been expressed a desire to have 
plug-in extensions (which might add some additional parameters of their own). 
However, from the view of the admin UI, all parameters share the common 
characteristic that they either can, or cannot, be altered by the . Using 
the generic abstraction that every parameter is a case of the Parameter class, 
and subclassing that to provide commonly seen variations (for example, 
"boolean") allows us implement a flexible structure that does not require 
handler recoding as the set of parameters changes.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Steve,

Here I agree with you.

It is useful for MM to be able to accept enterprise information when it is 
available.
OAuth is a mechanism that will be useful for some enterprises.
To the general public, being able to use enterprise identification from common 
sources such as Google or Twitter, is a "friendly" way identify a user and 
allow them to log into a MM system.

Within a MM installation, OAuth could be used in a more robust distributed 
implementation. However for our purposes, much simpler schemes such as Basic or 
Digest Auth is more than adequate for the intercommunication between components 
such as "core", "postorius", a message store, etc.

Richard

On Apr 28, 2013, at 11:07 PM, "Stephen J. Turnbull"  wrote:

> Xu Wang writes:
> 
>> As oauth supported google's userinfo API, one need to present a valid
>> google's oauth access token to get access.
>> s/google/mailman/g  on above statement, it will be true too.
> 
> I disagree, in the sense that Google (as an OAuth provider) is in the
> business of *providing* enterprise workflows such as AppEngine.
> That's why they need to be an OAuth provider.  Mailman is a support
> function for workflows (enterprise or otherwise).
> 
> So it's not a "Mailman" token.  It's an  token, and the
> enterprise, not Mailman, should be the provider.  If Mailman provides,
> then we have to take responsibility for foreseeing enterprise needs.
> 
> If we go Wacky's route and make everything as generic as possible, we
> may need the power of OAuth to handle all that genericity.  (We may
> also then need another 5 years to release Mailman 3)  But if we
> stick to the current role-based authorization model with a small fixed
> set of roles, then OpenID-like workflows (whether implemented via
> OAuth protocol or otherwise) should be enough.
> 
> If a site demands more control over authentication than public OpenID
> providers can afford, then Basic Auth over HTTPS fits into the "user
> has role" authorization model as well as OpenID does.  I don't see a
> need for Mailman to provide an authentication provider, and there are
> serious downsides to the proliferation of authentication providers.
> 
> Steve

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 9:58 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> The "root" of the tree covers all of the lists.  Under that top
>> node, we might create nodes for "Customer Plans", for example,
>> "Bronze", "Silver", "Gold" and "Platinum".  Each of these nodes
>> would specify some limits that applies to the level of service.
> 
> But here the limits apply to *principals*[1], not lists, AFAICS.

That is the case in my hypothetical example. However, the mechanism applies to 
any property of the lists such as a default value for some user preference.  In 
my example, the property is, perhaps, "Administrator can/cannot create a new 
list"
Equally, the content of a "Greeting Message" or the "Default Language", or any 
other property can be treated in the same manner.

> I could see this organization being usable in a case where ...

> It's not obvious to me that your way of doing things is better for
> this use-case.  If it's not plausible that it's better (I make no
> claim that it's not at this point), it fails to justify an experiment
> with a generic organization for lists.

You seem to be missing the point that "one size fits all", or in this case, one 
hierarchy, is not a flexible strategy.
By having a generic structure and allowing each installation to customize the 
hierarchy to fix their individual need, we provide a mechanism that better 
suits the needs of a larger group of installations.

>> Another right is the ability to permit the administrator to
>> associate additional persons to nodes within their portion of the
>> tree.  By doing so, that administrator "delegates" the ability to
>> perform certain operations to this added person.
> 
> This is more plausible as a use-case, since the "certain nodes" need
> not be all the nodes for that administrator.  OTOH, we already have
> "list owner" and "moderator" roles, and those *are* attached to each
> list.  It's not clear to me that we need to provide for adding
> additional roles, but I'll keep it in mind.

I'm advocating that we attach the roles (whatever they may be) to an entire 
collection of lists.
The purpose of a hierarchical structure, whether one fixed structure or a 
generic recursive one, is to provide a mechanism to
assist the "principal" in managing a number of lists that have common 
properties.

Actually, by establishing a flexible hierarchy, it may be possible to eliminate 
some of the functionally similar roles. For example, a "Domain Administrator" 
might be nothing more than a "List Administrator" attached to a higher node in 
the tree of Lists.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

My understanding of the use of oAuth to provide "login" information from 
Google, Twitter, etc. is based on the following description provided by Google.

Below is a trivial example of how to use Google's OAuth 2.0 endpoint to gain 
access to a Google API. It's a Python web application running on App Engine. 
The flow of the example is fairly straightforward:
When the application loads, it shows the you a "Login" link.
When you click that link, you are asked to login to Google and asked to release 
basic account information to the application (user consent).
If you grant consent, the application receives an access token.
Once it has the access token, the application presents the access token to the 
Google API that provides basic account information 
(https://www.googleapis.com/oauth2/v1/userinfo)
The application renders the basic account information in a simple table.
In particular, a user grants our server the permission to access some 
information pertaining to the user as it is stored by Google and accessed 
through their API for the purpose.

Based on that information, our server grants permission to the user thus 
identified and based on authorization data stored in our system. Once we have 
identified the user, our system can use tokens such as session keys, or other 
mechanisms, to maintain the association.

Richard

On Apr 28, 2013, at 2:42 PM, Xu Wang  wrote:

> On Sun, Apr 28, 2013 at 11:27 AM, Stephen J. Turnbull 
> wrote:
> 
>> Xu Wang writes:
>>> On Sun, Apr 28, 2013 at 12:15 AM, Stephen J. Turnbull <
>> step...@xemacs.org>
>>> wrote:
 Xu Wang writes:
 
> The problem is how do you "confirm ownership of the subscribed
> address" when a request coming with an access token.
 
 You don't.  That was done when the OAuth ID was linked to the address,
 using the usual 3-step handshake (submit the association, receive an
 email containing a secret, confirm ownership by replying with the
>> secret).
>>> 
>>> I'm not sure what you mean by "OAuth ID".
>> 
>> In the case of Mailman's use cases, it will typically be an email
>> address at Gmail, Yahoo, or Launchpad, or some other well-known OpenID
>> provider.  Often, but not necessarily, it will be the subscribed address.
>> 
>> 
> OpenID is about authentication. OAuth is about authorisation.
> What are we talking about here? Support to OpenID or support to OAuth or
> both?
> 
>> As a resource server, the API need to validate the access token but
>>> how to validate the access token is not part of OAuth.
>> 
>> This is some of the excess complexity (if you prefer, "enterprise
>> readiness") in OAuth 2.0.  In Mailman usage, the resource that the
>> consumer gets access to will be a user ID.  Eg, I might be "user:
>> stephen; name: Stephen Turnbull; email: step...@xemacs.org;
>> email:stephen.turnbull...@u.tsukuba.ac.jp; owner:
>> fs-p...@turnbull.sk.tsukuba.ac.jp; owner: xemacs-b...@xemacs.org ...;
>> OpenID: stephenjturnb...@gmail.com".  So when I login via OpenID
>> (which uses the OAuth v1 protocol AFAIK),
> 
> No OpenID does not uses OAuth protocol.
> 
> 
>> the provider (GMail) asks me
>> to verify who I am by presenting my credential (most users will think
>> of this as "getting the login screen"), and in turn it testifies to
>> the client that I own that email at GMail, and the consumer (eg, the
>> HyperKitty app) then looks it up, identifies me, logs me in as
>> "stephen", and gives me a cookie (session auth token).  The
>> authentication *is* the validation here.
>> 
> 
> Mailman can't use GMail as OAuth provider to protect mailman's own resource
> as a general authorization solution.
> 
> OAuth v2 envisions more complex scenarios where the client may present
>> the same token repeatedly, or consumers might hang on to them and
>> present them to the resource owner repeatedly, or even pass them on to
>> other consumers.  In those cases, yes, there will need to be
>> validation etc going on.  For example, the token might be a (ID, URI,
>> expiration-date) tuple encrypted with the resource owner's private
>> key.  Being able to decrypt and getting a syntactically correct,
>> unexpired tuple would then be validation of an authorization to fetch
>> that URI.  (In this particular case I'm thinking of "any valid user is
>> OK".)  This does require prior coordination between the provider and
>> the resource owner on token format and exchange of keys.
>> 
>> But AFAICS Mailman's currently envisioned applications don't require
>> this complexity.
>> 
> 
> As you put it,  mailman don't have to support OAuth, but if it dose, it's
> better stick to the protocol.
> 
> 
>> Do you have any ideas for Mailman that might require something more
>> fine-grained than just "this user is logged in"?
>> 
> 
> I'm new to mailman and have a very limited knowledge about what  kind of
> "fine-grained" authorization it may need other than authentication. (read:
> Xu had no clue ...)
> 
> From the api implementation point of view, a role base aut

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull  wrote:
> The rest of your post is just a reiteration of your religious belief that 
> generic is good.

Call it "religion" if you wish. It is based on DECADES of experience, many of 
which involved reworking existing code to handle some changed conditions.

> I know the theory, but without use cases I will devote my efforts
> elsewhere, and ignore complaints that my code or my advisee's code is
> insufficiently general or that it ignores a theoretical design that
> has no code or use case to back it up.


Where is your design to handle the delegation of (restricted) permissions to 
alter list settings, create new lists, add moderators or administrators, etc.?

I am, at least, proposing a framework which would be able to address these 
issues.

This sounds as if you are using the "But you haven't actually built the entire 
system, therefore I can dismiss anything that you propose as a design concept" 
excuse to dismiss any ideas that are "Not Invented Here"
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

I am thinking of "delegation" in the context of administering list properties 
and preferences.

Assume a hierarchy of lists handled by one (or more) servers that comprise a MM 
system.

Various "persons" could be assigned authority to make changes that affect lists 
within portions of the tree.
those changes might in things such as setting the default language or the 
ability to create a new list.

In the virtual hosting scenario, provides a number of possible opportunities to 
illustrate how this might be used.

The "root" of the tree covers all of the lists.
Under that top node, we might create nodes for "Customer Plans", for example, 
"Bronze", "Silver", "Gold" and "Platinum".
Each of these nodes would specify some limits that applies to the level of 
service.
Let us assume that the Bronze service plan allows the customer to have only 
lists set up by the Provider staff.
That user might still be allowed to set other parameters, for example, the 
subscription policy and the"welcome message".
Under the Silver Plan, a customer might be allowed to set up new lists within 
their own email-domain.

In both of these cases, a subordinate node would be created under the 
appropriate "plan" node for the list(s) of that customer.
And under those nodes, we would find various individual lists.

Now, within our permissions system, we would grant the customer administrator 
permissions to alter certain parts of the list parameters. In my example case, 
the right to create new lists would not be granted to the customers in the 
Bronze plan, but would be granted to those in the Silver plan.

Another right is the ability to permit the administrator to associate 
additional persons to nodes within their portion of the tree.
By doing so, that administrator "delegates" the ability to perform certain 
operations to this added person.

Note: I am not trying to present the complete set of details, only trying to 
indicate how such a framework might be utilized.

The reason that a generic mechanism has value is that the same type of 
"permissions" logic is utilized for any parameter describing the list behavior. 
Whether you are selecting the default user preference to "receive digest" or 
specifying the email address or website URL through which someone can 
"unsubscribe", except for the filtering on permissible data values, the 
mechanisms needed to handle an input form are very similar.


Richard

On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> Yes, initially generating a more generic structure than the ad hoc
>> one in place (which doesn't even attempt to address delegation)
> 
> Aha!  Something that looks like a concrete use case!  But what is
> "delegation"?  I mean, "who delegates what to whom?  And why does
> Mailman need to address it?  What code needs to be written to address
> it?
> 
> The rest of your post is just a reiteration of your religious belief
> that generic is good.
> 
> I know the theory, but without use cases I will devote my efforts
> elsewhere, and ignore complaints that my code or my advisee's code is
> insufficiently general or that it ignores a theoretical design that
> has no code or use case to back it up.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 11:15 AM, Stephen J. Turnbull  
wrote:

> Richard Wackerbarth writes:
>> Note that "core" doesn't NEED the structure (of list heiarchy) to function.
> in deciding on design principles we need to evaluate simplicity, 
> practicality, etc
> from the point of view of the people involved.
Agreed.

> I think the tried and true hierarchy (site -> virtual hosts -> lists) matches 
> some a
> natural hierarchy in administrative responsibility and user understanding of 
> this corner of the Web.
That matches ONE organizational hierarchy. There is no reason that you cannot 
use a more general structure and still follow that organizational structure.

>  That makes it easier to think about requirements and write code to satisfy 
> them.
Not necessarily.


>> The structure can be imposed by having the interface agent impose
>> constraints on the members of a group of lists and mapping an
>> operation on the group into that operation on each of its members.
> 
> Yes, and we'll have to create a language to express those constraints
> and an interpreter to enforce them, *and* create objects like "site"
> == Mailman instance and "vhost" out of the abstract groups.  Costs,
> benefits, which is bigger?
> 
>> If we use a MPTT key
> 
> "Ministry of Posts, Telegraph, and Telephone"?  "mildly paranoic teletype"?

Modified Preorder Tree Traversal

> Sites and virtual hosts have attributes besides lists (websites, the 
> "mailman" list, owner and admin
> addresses, ...).  There should be objects that correspond to those concepts 
> to carry those attributes.

I think that I view it differently.  EVERY list has, for example, an "admin 
address". If there is only one list, to the user(administrator) that attribute 
belongs to the (only) list.  It is only when you have a collection of lists 
that share a common value that a hierarchy adds value. In that case, by 
defining a default value to the node representing the collection and specifying 
"inherit from parent" in all of the sub-nodes, you can, administratively 
simplify the maintenance of the value to be used in each instance.

>> The only real issue is how we would express constraints that get delegated.
>> 
>> But we need to address that issue for any structure that we establish.
> 
> True, but it's not a question of need to or not, it's a question of
> costs and benefits.  Generic code is more expensive to create and
> maintain in many cases.  I suspect it will be here, as well.

Yes, initially generating a more generic structure than the ad hoc one in place 
(which doesn't even attempt to address delegation) is a bit more expensive for 
the first few parameters. However, in the log run I suspect that it won't be 
more expensive. Creating a single, reusable mechanism for the specification of 
delegation of authority will actually produce an easier-to-maintain scheme. 
And, ad hoc approaches are notorious for becoming unmaintainable.

>  Without use cases for the generality, it's hard to see the benefits.  When 
> do you expect the generality to be of use?
> 
>> Virtual hosting is the primary example of the need for a
>> hierarchical administrative structure. However, it can also be
>> useful in corporate structures where the email address space might
>> be partitioned in a quite different manner.

There is no need to make a distinction between the levels in your list 
hierarchy tree.
Treating each level as a specific case of a generic structure allows reuse of a 
common code base.

>> From a design perspective, the "core" message handler should be
>> distinct from the configuration administrator.
>> 
>> Message handling uses the current value of various configuration
>> parameters. It need not, and should not be concerned with the
>> mechanics related to the setting or modification of those
>> parameters.
>> 
>> Since these parameters seldom change, an effective caching
>> mechanism would address access performance issues.
> 
> I have no clue what you're trying to express here.

This is addressing the modularity of the system, separating functionality and 
utilizing particular views of the stored data rather than dictating how the 
data is stored and manipulated.

>  I don't see any performance issues, except that programmers whose brains 
> have exploded
> from cognitive overload tend not to produce double-digit KLOC/hour.
> My concern is entirely whether the design you propose simplifies the
> job of meeting the common requirement of creating a (1 to 3 level)
> hierarchical organization of lists (the third level being the children
> of umbrella lists), or serves important

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 28, 2013, at 2:15 AM, Stephen J. Turnbull  wrote:

> Xu Wang writes:
>> The problem is how do you  "confirm ownership of the subscribed address"
>> when a request coming with an access token.
> 
> You don't.  That was done when the OAuth ID was linked to the address,
> using the usual 3-step handshake (submit the association, receive an
> email containing a secret, confirm ownership by replying with the secret).

In many installations, the linking may not require the email handshake.
An installation may choose to "trust" that the third party issuing the access 
credential has already performed sufficient vetting of the association.

I'm thinking of things like BrowserID credentials or Google/Twitter/Facebook 
issued credentials.

However, that is a local "policy" whose decision involves a tradeoff between 
the level of assurance and the ease in establishing the association.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 10:36 AM, Stephen J. Turnbull  wrote:
> Richard Wackerbarth writes:
>> Primary Key == An identifier of the server's choice that identifies
>> a unique instance of the specified resource.  It is important to
>> note that the client CANNOT rely on any particular scheme for
>> mapping other keys to this identifier.
> 
> That's true for resources that were added after the client was
> written, but there's no reason I can see why we shouldn't make it easy
> for people to write URIs by hand if they know something about Mailman.

Being able to "write URIs by hand" is a violation of the HAL design because it 
locks the interface into a particular implementation. The design principal is 
that "things will change".

Although there is an advantage in having URIs that convey semantic value, (for 
example using a "short name" to designate one of the lists on the server), we 
should leave that mapping to some configuration aspect of the particular 
installation.

Remember that the REST URIs are intended to be mechanisms for automated agents 
to access resources. They are not intended to be the substitute for a user's 
search interface.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 9:15 AM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> It is not necessary to have more than a flat collection of lists.
> 
> I don't know how it will be represented, but we *do* need to support
> virtual hosting, where the mailman administrator delegates site
> administration to the owner of the virtual host.

A list is a first class object. Each list has its own set of parameters which 
characterize it.
One portion of those characteristics is the administrative permissions 
associated with the creation and alteration of the list.

Groupings of lists simply provides a "shorthand" for the description of 
characteristics which are common to the group.

>> In fact, that approach has the advantage that each list can be
>> allowed to have individual configuration parameters. At the
>> present, he has attached the "base web URL" to the
>> email_domain. Instead, I would like to have the ability to set that
>> on a per-list basis.
> 
> I think that's reasonable.
> 
>> Rather than defining a specific structure, I would substitute a
>> more generic structure defining collections of lists. This tree
>> could be configured to represent any organizational hierarchy that
>> the installation desires.
> 
> Such flexibility has benefits and costs.  How many of our users will
> need/want this flexibility?  (Genuine question.  I personally don't
> want it, so it's hard for me to estimate.)

The advantage in using the generic structure is that it does not impose any 
pre-supposed structure on the collection of lists.
Note that "core" doesn't NEED the structure to function. The structure can be 
imposed by having the interface agent impose constraints on the members of a 
group of lists and mapping an operation on the group into that operation on 
each of its members.

If we use a MPTT key as the list/list-group identifier, we get the generic 
hierarchy as a byproduct.

The only real issue is how we would express constraints that get delegated.

But we need to address that issue for any structure that we establish.

Virtual hosting is the primary example of the need for a hierarchical 
administrative structure. However, it can also be useful in corporate 
structures where the email address space might be partitioned in a quite 
different manner.

>From a design perspective, the "core" message handler should be distinct from 
>the configuration administrator.
Message handling uses the current value of various configuration parameters. It 
need not, and should not be concerned with the mechanics related to the setting 
or modification of those parameters.

Since these parameters seldom change, an effective caching mechanism would 
address access performance issues.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

[Richard Wackerbarth]

I don't think that "we" have the expertise to create a "secure" system. At 
best, we can adopt good practices and provide an obscured traffic stream. I 
consider anything more to be beyond the scope of the MM project.

On Apr 27, 2013, at 8:22 AM, Stefan Schlott  wrote:

> On 27.04.2013 06:45, Stephen J. Turnbull wrote:
> 
>>> 2. Your list has elevated security requirements. In this case, you can
>>> use gpg-agent to manage the secret key (and its passphrase).
>> 
>> I don't understand what threat you propose to address in this way.
>> It's true that you can prevent the attacker from getting access to the
>> key (using agent forwarding or a token, it need not be on the exposed
>> host at all), but we're assuming he has access to the host and the
>> Mailman process.
> 
> The gpg-agent approach protects you from all storage-related attacks:
> - unencrypted backups
> - physical access to the harddrive
> - etc.
> 
> It does not protect from attackers who have access to the contents of
> the computer's RAM:
> - raw memory access and scanning for the secret key (requires root)
> - memory dump via DMA-enabled interfaces (firewire, pc-card, ...)
> - cold boot attacks
> 
> 
> Stefan
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 8:19 AM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:
> 
>>> "ABCDEFG" is what?  The list?
>> 
>> Yes. But note that it is some pk provided by the list store.
> 
> "pk" ?

Primary Key == An identifier of the server's choice that identifies a unique 
instance of the specified resource.
It is important to note that the client CANNOT rely on any particular scheme 
for mapping other keys to this identifier.

>>>> https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
>>>>  would return the URI representing the list
>>> 
>>> Why have you changed the order of components here?
>> 
>> Because I don't know the pk for the list. I wish to look it up.
> 
> So "attribute/posting_address/test_l...@example.com" is a query that
> means "give me a way to indicate this list"?

Yes

> These URIs are pretty ugly.  Surely we can do better?

Perhaps we can. But we need to conform to the HAL framework style.

As I understand it, the consumer understands the semantics of various links, 
but the actual links are "discovered" as a part of previous queries and not 
"constructed".  As such, the links depend more on the ease of implementation 
rather than their "beauty".

Perhaps Xu has experience and can enlighten us.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 26, 2013, at 11:32 PM, Richard Wackerbarth  wrote:

> Additionally, I would generalize the grouping of lists into a hierarchical 
> tree that represents the enterprise organization rather than aspects of the 
> internet namespace.

Stephen,

Barry has introduced a small amount of hierarchy into the grouping of lists. 
(E.g. The domain)
Within that hierarchy, he at least alludes to the delegation of authority to 
list owners.

It is not necessary to have more than a flat collection of lists. In fact, that 
approach has the advantage that each list can be allowed to have individual 
configuration parameters. At the present, he has attached the "base web URL" to 
the email_domain. Instead, I would like to have the ability to set that on a 
per-list basis. There is no structural constraint that requires lists to share  
such common values, but I do acknowledge that it is expedient for the system to 
be able to generate the list specific value by some algorithm that is applied 
to a class of lists.

Rather than defining a specific structure, I would substitute a more generic 
structure defining collections of lists. This tree could be configured to 
represent any organizational hierarchy that the installation desires. Various 
persons could then be granted administrative rights over particular subtrees. 
Algorithmic constraints can be assigned to a collection insuring that each list 
therein complies with the enterprise schema.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

I, and I think Stephen, are advocating the use of oAuth as a "login" method. 
Just as BrowserID provides a third party identifier, Google, Twitter, Facebook, 
etc. provide similar service through oAuth protocols. MM should be configurable 
to accept those, or other enterprise-provided identifiers.

On Apr 27, 2013, at 2:42 AM, Xu Wang  wrote:

> For OAuth , you need to implement token
> based auth in API, as well as a provider service because there is no open
> OAuth provider service for third party API out there :-(
> 
> The provider service has to implement  application registration, user auth,
> token validation and distribution (for oauth 1a, access token need to be
> pushed to or shared with API).
> 
> In my view, OAuth really belongs to an enterprise system, rather than a
> specific api or one application. It requires a existing robust web-based
> auth system on the provider's site.
> 
> This will also make the API less "independent" because it is depending on
> the provider service and provider's auth system.
> 
> With that said, the API could have a plugin that support  "token-based"
> authorization, with an out-of-band token distribution/validation and
> management service, whatever it would be.
> 
> Only if there is a strong 3-legged auth use case, should one push to this
> controversy route.
> 
> Xu Wang
> 
> 
> On Fri, Apr 26, 2013 at 11:53 PM, Stephen J. Turnbull 
> wrote:
> 
>> Abhilash Raj writes:
>> 
>>> Hi all,
>>> I wrote a brief summary[1] of this thread.
>> 
>> You've misinterpreted or mistyped a couple things I wrote:
>> 
>> I'm not against OAuth in general, just against Mailman being an OAuth
>> *provider*, or bundling one, because we can't support it properly.
>> Users should get auth stuff from somebody whose primary interest is
>> security stuff.
>> 
>> When I write authentication and authorization should be avoided, I
>> don't mean Mailman doesn't authenticate and authorize users.  I mean
>> the implementation should be delegated to robust, well-tested modules
>> or external applications (eg, Apache) whereever possible.
>> 
>> The last quote needs to be fleshed out.  "This practice" refers to not
>> exposing keys and other secrets to the whole application, including
>> cooperating processes.  If authentication can be done in one place and
>> an internal session or one-time authorization be granted, that's what
>> should be done, rather than exposing user credentials to other parts
>> of the application to do their own authentication and authorization.
>> 
>> In making such a summary, I think it would be better to organize by
>> topic.  Eg, a partial outline:
>> 
>> REST API for extended user profiles
>>  Authorization
>>Trusting local connections
>>HTTP Basic
>>OAuth
>>- Recommended for "outside world" [Florian]
>>- Advocates including an OAuth provider as a non-default,
>>  experts-only option [Florian]
>>- Opposes bundling an OAuth provider [Stephen]
>>- OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
>>  now? [Stephen]
>>- Don't need an OAuth provider to share authorizations (in fact,
>>  at least in OAuth 2.0, providers don't provide sharing at all)
>>  [Stephen]
>>- Implementing OAuth provider doesn't provide the benefits of
>>  OAuth (ie, add an OAuth provider means users have yet another
>>  set of credentials to manage) [Stephen]
>>- OAuth architecture = provider + client + consumer [Richard]
>>- Agrees to Mailman as OAuth consumer, not provider [Richard]
>>- OAuth may be overengineering, at first [Barry]
>>  Database schemas
>>  Database implementations
>>  Wire Protocol
>> etc...
>> 
>> Also, in that format it's easy to reorganize:
>> 
>> REST API for extended user profiles
>>  Authorization
>>Trusting local connections
>>HTTP Basic
>>OAuth
>>- OAuth architecture = provider + client + consumer [Richard]
>>- Use client in Mailman?
>>  - Recommended for "outside world" [Florian]
>>  - Agrees to Mailman as OAuth consumer, not provider [Richard]
>>  - OAuth necessary?  Why isn't HTTPS + Basic Auth good enough for
>>now? [Stephen]
>>  - OAuth may be overengineering, at first [Barry]
>>- Use provider in Mailman?
>>  - Advocates including an OAuth provider as a non-default,
>>experts-only option [Florian]
>>  - Opposes bundling an OAuth provider [Stephen, Richard]
>>  - Implementing OAuth provider doesn't provide the benefits of
>>OAuth (ie, add an OAuth provider means users have yet another
>>set of credentials to manage) [Stephen]
>>  - Don't need an OAuth provider to share authorizations (in fact,
>>at least in OAuth 2.0, providers don't provide sharing at all)
>>[Stephen]
>>  Database schemas
>>  Database implementations
>>  Wire Protocol
>> etc...
>> 
>> By the way, don't go out of your way to reorganize what you've already
>> done, except as it's us

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

I think that we are advocating the same approach.
Your example is better tailored to actual MM resources and can be substituted 
for the one that I referenced.
Note: I am "speaking" conceptually. The actual hard design of the details would 
be the scope of work for a GSoC project.
The easiest way to present all of the details is to actually create a reference 
implementation. :)

On Apr 27, 2013, at 3:21 AM, Xu Wang  wrote:

> Here is an example of what it might look like for "user" resource returned
> by the api (without any auth):
> 
> curl http://localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/
> HTTP/1.0 200 OK
> Content-Type: application/json
> Content-Length: 1232
> Cache-Control: max-age=20,must-revalidate
> Expires: Sat, 27 Apr 2013 08:07:04 GMT
> ETag: 8252e88a72eea8fd4c93aa57435a3857f618d5d1
> Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC
> Date: Sat, 27 Apr 2013 08:03:44 GMT
> 
> {
>"_id": "517b5560f84a4b13d239fc59",
>"_links": {
>"collection": {
>"href": "localhost:5000/api/v1/users/",
>"title": "users"
>},
>"parent": {
>"href": "localhost:5000/api/v1",
>"title": "home"
>},
>"self": {
>"href":
> "localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/",
>"title": "user"
>}
>},
>"created": "Sat, 27 Apr 2013 04:34:40 UTC",
>"email": "swesg...@baqlwrzxqfjpofpy.nl",
>"firstname": "wtegrglnub",
>"lastname": "bjsbvjrn",
>"roles": "level_3",
>"subscriptions": [
>{
>"href":
> "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc56/",
>"options": {
>"option_0": "qifqk",
>"option_1": "qyqyx",
>"option_2": "dirkf",
>"option_3": "yjrtv",
>"option_4": "mljew"
>},
>"ref": "517b5560f84a4b13d239fc56",
>"title": "mailing list"
>},
>{
>"href":
> "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc58/",
>"options": {
>"option_0": "aixqy",
>"option_1": "triwy",
>"option_2": "aponq",
>"option_3": "xmorj",
>"option_4": "szmig"
>},
>"ref": "517b5560f84a4b13d239fc58",
>"title": "mailing list"
>},
>{
>"href":
> "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/",
>"options": {
>"option_0": "ltops",
>"option_1": "bojfl",
>"option_2": "qjsyl",
>"option_3": "ndtof",
>"option_4": "diass"
>},
>"ref": "517b5560f84a4b13d239fc54",
>"title": "mailing list"
>}
>],
>"updated": "Sat, 27 Apr 2013 04:34:40 UTC"
> }
> 
> and let's follow the last of mailing list link in the users.subscriptions:
> 
> $ curl -i 'localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/'
> 
> HTTP/1.0 200 OK
> Content-Type: application/json
> Content-Length: 711
> Cache-Control: max-age=20,must-revalidate
> Expires: Sat, 27 Apr 2013 08:05:00 GMT
> ETag: eea6cfa4fc6311a1ea3c5c4189597ab962369d34
> Last-Modified: Sat, 27 Apr 2013 04:34:40 UTC
> Date: Sat, 27 Apr 2013 08:04:40 GMT
> 
> {
>"_id": "517b5560f84a4b13d239fc54",
>"_links": {
>"collection": {
>"href": "localhost:5000/api/v1/mlists/",
>"title": "mlists"
>},
>"parent": {
>"href": "localhost:5000/api/v1",
>"title": "home"
>},
>"self": {
>"href":
> "localhost:5000/api/v1/mlists/517b5560f84a4b13d239fc54/",
>"title": "mailing list"
>}
>},
>"address": "auxri...@rdrfzfmvluylkegy.ca",
>"created": "Sat, 27 Apr 2013 04:34:40 UTC",
>"description":
> "krtejcbwmedzftdvjwagmbqkkiajubnzezxstahexvkrjncecdwsyfjlbobgjuxevwgflxlnemqtqcjz",
>"option": {
>"option_0": "vwmum"
>},
>"owners": [
>{
>"href":
> "localhost:5000/api/v1/users/517b5560f84a4b13d239fc59/",
>"name": "wtegrglnub bjsbvjrn",
>"ref": "517b5560f84a4b13d239fc59",
>"title": "user"
>}
>],
>"updated": "Sat, 27 Apr 2013 04:34:40 UTC"
> }
> 
> 
> 
> On Sat, Apr 27, 2013 at 1:00 AM, Xu Wang  wrote:
> 
>> Here is my take on the basic system requirements and design issues:
>> 
>> System Components:
>>   * A RESTful 
>> API
>>  -
>> a mini-server that servers restful calls.
>>   * A persistent store - a schemaless or relaxed datasource, e.g. Mongodb
>>   * An authn/authz service to support api authn/authz and account
>> management
>>   options for authn:
>>- no auth, open to localhost, off load the AC to clients.
>>- base 
>> auth,
>> username/pw

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 2:42 AM, "Stephen J. Turnbull"  
wrote:

> Richard Wackerbarth writes:
> 
>> https://server.example.com/mailman/list/ABCDEFG/attribute/join_address
>> returns the email address to which subscription requests should be
>> sent.
> 
> "ABCDEFG" is what?  The list?

Yes. But note that it is some pk provided by the list store. It may not have 
any recognizable relationship to other characteristics of the list ( such as a 
"common name" or FQDN )
> 
> I think the short prefix /mailman/ should be reserved for traditional
> and anonymous requests.  /mailman/rest_api/ or some such for the
> REST API.

I don't disagree. I would reserve /.well_known/mailman/ as an access point that 
delivers the "root" of the REST API tree and, otherwise, make no assumption 
about the location of it in URI space.

> 
>> https://server.example.com/mailman/list/ABCDEFG/attributes
> 
> This is what you mean by self-documenting?

No. This is an access point for the document. If fetched as JSON or XML, it 
would be machine parseable. If fetched as HTML/text, it would be human readable.

>  Presumably it returns not only the attribute names, but their ranges (types) 
> and docstrings?
> 
>> https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
>>  would return the URI representing the list
> 
> Why have you changed the order of components here?

Because I don't know the pk for the list. I wish to look it up.
> 
>> https://server.example.com/mailman/attribute/posting_address/test_l...@example.com/attribute/join_address
>>  might return test_list-j...@example.com
> 
> Huh?  This isn't a syntax error?

Probably is syntactically incorrect. The email address would need to be URL 
escaped.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 27, 2013, at 12:51 AM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:
> 
>> subscription - the binding of an email address to a list.
> 
> Also preferences are bound here.  (This is not the only kind of thing
> that preferences can be bound to, but experience shows that we need
> per-subscription preferences.)

Complete agreement.

> 
>> First, rather than having multiple attributes and preferences as
>> "columns" in a table, I would portray them as multiple rows in a
>> table where the attribute names are a key that is used to select
>> the corresponding value.
> 
> I have no clue what that sentence means, but I suppose that you mean
> that the current representation is something like (in mock-ABNF)
> 
>member := address fullname *attribute
> 
> and you want to change that to
> 
>member := address fullname preferences
>preferences := *attribute
> 
>> Additionally, I would generalize the grouping of lists into a
>> hierarchical tree that represents the enterprise organization
>> rather than aspects of the internet namespace.
> 
> Example?
> 
>> By treating the preferences as a table of key-value pairs, we can
>> easily extend the list of elements with plug-in modules without
>> having to change the data handling or display mechanisms.
> 
> Ah so you don't mean what I wrote above, you want to represent
> preferences as a table with
> 
>row = preference-owning-entity att_name att_key

> 
> ?

Correct. But isn't it

row = preference-owning-entity att_name att_value
?

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Abhilash,

Thanks for the summary.

Let me add a bit about what I think we should present in this interface.

First, it should be RESTful and self documenting.

The format of information delivered will be controlled by the http Accept: 
header
The standard representation for communication between various modules of the MM 
system (core, user-manager,webUI, etc.) will be "application/hal+json"


https://server.example.com/mailman/list/ABCDEFG/attribute/join_address returns 
the email address to which subscription requests should be sent.

https://server.example.com/mailman/list/ABCDEFG/attributes

https://server.example.com/mailman/attribute/posting_address/test_l...@example.com
 would return the URI representing the list

https://server.example.com/mailman/attribute/posting_address/test_l...@example.com/attribute/join_address
 might return test_list-j...@example.com


See https://gist.github.com/hjr3/2289546 (an E-commerce platform specification) 
to get a representative idea of the json formatting.

I envision the simplified model to have the following core resources:

user -  A person
address - An email address each address is owned by one person
credential - An authentication binding associating a user with an identifier 
such as username/password, browserid, or oAuth

list - A mailing list. Lists have attributes that apply to the list and also 
have a set of preferences which supplies defaults for subscription preferences

subscription - the binding of an email address to a list.

attributes - a dictionary of the parameters that characterize the list

preferences - a dictionary of the parameters that apply to a subscription

I am suggesting two primary differences from the MM core style of 
representation.
First, rather than having multiple attributes and preferences as "columns" in a 
table, I would portray them as multiple rows in a table where the attribute 
names are a key that is used to select the corresponding value.

Additionally, I would generalize the grouping of lists into a hierarchical tree 
that represents the enterprise organization rather than aspects of the internet 
namespace.

By treating the preferences as a table of key-value pairs, we can easily extend 
the list of elements with plug-in modules without having to change the data 
handling or display mechanisms.

Richard

On Apr 26, 2013, at 7:00 PM, Abhilash Raj  wrote:

> Hi all,
> I wrote a brief summary[1] of this thread. Its in the form of notes sorted
> according to participants and a small summary at the end( showing off
> whatever I could understand reading the thread twice from head to toe ).
> However I might have misunderstood ( or not understood at all ) or missed a
> few things, forgive me for that.
> 
> [1]: https://gist.github.com/maxking/5471211
> 
> Thanks,
> Abhilash
> 
> 
> On Sat, Apr 27, 2013 at 1:06 AM, Terri Oda  wrote:
> 
>> So... What have we decided? :)
>> 
>> From my fuzzy "I read my email on a plane after delta woke me up at 3am to
>> tell me my flight was cancelled" level of recollection
>> 
>> The few things I we actually agreed on:
>> 
>> - We like the idea of a rest interface.
>> 
>> - That interface/API should probably be decided now and relatively
>> permanently
>> 
>> - then implementation details can be changed later as necessary (so it
>> doesn't matter if we start with Django or whether mailman-user reads from
>> mailman-core or vice versa, as long as it gets done and fulfills the
>> promises of the API)
>> 
>> - something something oauth something
>> 
>> Can someone sketch out what that REST interface will look like as an
>> actual architectural document that we can comment on?  I don't care who
>> does this; we just need somewhere to start, so any subscriber to this list
>> can probably summarize the emails into a useful document.
>> 
>> Terri
>> 
>> 
>> 
>> __**_
>> Mailman-Developers mailing list
>> Mailman-Developers@python.org
>> http://mail.python.org/**mailman/listinfo/mailman-**developers
>> Mailman FAQ: http://wiki.list.org/x/AgA3
>> Searchable Archives: http://www.mail-archive.com/**
>> mailman-developers%40python.**org/
>> Unsubscribe: http://mail.python.org/**mailman/options/mailman-**
>> developers/raj.abhilash1%**40gmail.com
>> 
>> Security Policy: http://wiki.list.org/x/QIA9
>> 
> 
> 
> 
> -- 
> Abhilash Raj
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http:

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

[Richard Wackerbarth]

Although there might be a place for the use of OpenPGP for identification of 
users to the WebUI, such a project would not, in itself, be sufficiently 
complex for a GSoC project. If you are interested in such an effort, it would 
need to be combined with other (preferably related) aspects of authentication 
such as identification of submitted email messages.


On Apr 22, 2013, at 6:29 AM, Paul Wise  wrote:

> On Sun, Apr 7, 2013 at 5:19 AM, Abhilash Raj wrote:
> 
>> I am a undergrad student interested in OpenPGP integration in mailman as a
>> GSOC project this summer.
> 
> Here is a semi-related idea; use OpenPGP instead of passwords for
> authentication to the web interface, possibly using monkeysphere:
> 
> http://web.monkeysphere.info/
> 
> -- 
> bye,
> pabs
> 
> http://wiki.debian.org/PaulWise
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC Project idea: OpenPGP integration

[Richard Wackerbarth]

I echo Stephen's comments. Although I try to lurk on the #mailman channel most 
of the time,  being half a world away from him, I am most likely to be at the 
keyboard after 1100 UTC and before 0200 UTC.

However, I strongly suggest that you begin more specific questions on this 
mailing list.

Richard "Wacky" Wackerbarth

On Apr 22, 2013, at 3:33 AM, Stephen J. Turnbull  wrote:

> Abhilash Raj writes:
> 
>> Can you tell about who is going to mentor this(OpenPGP integration with
>> mailman)
> 
> I would guess the official mentors are likely to be myself and Wacky
> (Richard Wackerbarth).  Joost isn't official (why not? -- you get a
> T-shirt! :-) but he has expressed interest and offered help.
> 
> Lack of a secure through-the-mail channel for several aspects of
> Mailman is a pain point for many users, though, so I suspect there
> will be a lot of interest (including suggestions and even code
> contributions) from non-mentors.  I strongly suggest that you keep the
> discussion on this list for that reason.
> 
> I will also try to be available on IRC Freenode #mailman as yaseppochi
> for the next two days (more or less 1am to 1pm UTC), and
> intermittently after that.  Other mentors will probably be there, too.
> 
>> so that I can discuss a few things about the application? Also
>> others can you please give me a few suggestion about proposal on
>> the idea that is discussed in this[1] thread.
>> 
>> [1]:
>> http://mail.python.org/pipermail/mailman-developers/2013-April/022675.html
>> 
>> Thanks,
>> 
>> 
>> On Wed, Apr 10, 2013 at 3:09 PM, Joost van Baal-Ilić <
>> joostvb-mailman-develop...@mdcc.cx> wrote:
>> 
>>> Hi Abhilash Raj,
>>> 
>>> Abhilash Raj raj.abhilash1 at gmail.com schreef:
>>>> On Sun, Apr 7, 2013 at 4:47 AM, Daniel Kahn Gillmor
>>>> wrote:
>>>>> On 04/06/2013 06:53 PM, Paul Wise wrote:
>>>>>> On Sun, Apr 7, 2013 at 5:19 AM, Abhilash Raj wrote:
>>>>>> 
>>>>>>> I am a undergrad student interested in OpenPGP integration in mailman
>>>>>>> as a GSOC project this summer.
>>> 
>>>>> neat, i'm glad to hear it!
>>> 
>>> Be aware however: it's not an easy task, as Daniel Kahn Gillmor pointed
>>> out.
>>> 
>>>>>> I'm not sure about the scope of your project but you may want to
>>>>>> review some prior efforts:
>>>>>> 
>>>>>> http://schleuder2.nadir.org/
>>>>>> http://www.synacklabs.net/projects/crypt-ml/
>>>>> 
>>>>> see also:
>>>>> 
>>>>>  http://non-gnu.uvt.nl/mailman-pgp-smime/
>>>>>  http://sels.ncsa.illinois.edu/
>>>>> 
>>>>>> My pet favourite feature from the lurker mail archiver is showing
>>>>>> photos from OpenPGP keys in the archive pages.
>>>>> 
>>>> Thanks for these links. I am currently going through these projects to
>>>> figure out the implementation part of the OpenPGP into mailman. Also
>>> trying
>>>> to use the mailman-php-smime patch to figure out how it is implemented.
>>> 
>>> The Mailman Secure List Server Patch hasn't been touched since 2010-09.
>>> It's a
>>> patch for mailman-2.1.15, not for the development branch.  However,
>>> studying it
>>> will surely give you some inspiration.  Some code might be reusable too.
>>> 
>>> If you'd like to discuss details of this patch, you're invited to join the
>>> list
>>> at ssls-...@ulm.ccc.de.
>>> 
>>> I'd be glad to help you dealing with the work.
>>> 
>>> Bye,
>>> 
>>> Joost
>>> 
>>> --
>>> http://mdcc.cx/ xhttp://ad1810.com/
>>> 
>> 
>> 
>> 
>> -- 
>> Abhilash Raj
>> ___
>> Mailman-Developers mailing list
>> Mailman-Developers@python.org
>> http://mail.python.org/mailman/listinfo/mailman-developers
>> Mailman FAQ: http://wiki.list.org/x/AgA3
>> Searchable Archives: 
>> http://www.mail-archive.com/mailman-developers%40python.org/
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/mailman-developers/stephen%40xemacs.org
>> 
>> Security Policy: http://wiki.list.org/x/QIA9
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Barry,

Are you starting to come around to the concept that I have been advocating for 
a long time?

In particular, rather than "owning" the user information, "core" simply views 
it.

I assume that you are reluctant to store "foreign keys" to external databases 
because you worry that consistency might be broken when another process alters 
the database.

I ask that you consideration the following as it applies to that view:
First, as viewed from the other side (the enterprise, etc.), your same concerns 
apply to accessing their "user". For example, when you store the user password, 
how do they assure availability and consistency?

Second, particularly if you separate the administration functions, "core" 
message handling should, at most, rarely care about the "user" information. The 
subscription information, which seldom changes, should contain sufficient 
information to handle the time-critical task of message dispatch.

Richard
 
On Apr 18, 2013, at 8:20 PM, Barry Warsaw  wrote:

> Terri, thanks for kicking off this discussion!
> 
> On Apr 18, 2013, at 01:34 PM, Terri Oda wrote:
> 
>> On 13-04-18 2:28 AM, Stephen J. Turnbull wrote:
>>> Main comment: Sounds like LDAP to me.
> 
>> Actually, this is a really important comment.  I was sort of wondering that
>> too when I started writing the description.  LDAP is a moderately frequently
>> requested feature already.  Would it make sense to use that probably rather
>> than rest, or make a rest framework that talked to ldap under the hood?
> 
> I agree that this is a really interesting suggestion.
> 
> What's interesting to me about it is that this acknowledges that
> administrative control of this extra user information may fall to folks not at
> all directly involved in mailing list administration.
> 
> You can imagine that a company would already have their LDAP database of
> additional user information, from postal addresses, to phone numbers, to IRC
> handles, pictures and icons, birthdays, etc.  Further, I can imagine that if
> that company were to be running MM3 and HyperKitty, they'd probably not want
> to duplicate that information in multiple databases, they'd just want to pull
> the pictures and IRC nicks out of LDAP.  For their purposes, their LDAP
> database *is* their user database.
> 
> Of course, some of that information may also be used in part or in whole for
> the core, e.g. display names (which actually are useful in places, such as
> crafting the From header for a virgin notification).
> 
> Now, at least conceptually, I've always thought about the user database as one
> of the three pillars of information in the core, the other two being the list
> database and the message store.  This is why for example subscriptions do not
> just link a foreign key for the mlist to a foreign key to the address, because
> this would not allow for separation of these two pillars[1].
> 
> Furthermore, the use of interfaces internally is meant to allow for
> alternative implementations of the lowest database layer of these pillars,
> without affecting any functionality above it.  So let's say even in the core,
> user passwords, display names, and preferences were kept in LDAP.  An
> alternative implementation of user.py would pull the data in from there and as
> long as it satisfied the syntactic and semantic APIs of the IUser interface,
> everything else in MM3 would continue to work.
> 
> You could extend this to the idea expressed elsewhere that the core could use
> this external user database.  Why not?  The external user database could be
> accessible over REST or a via a database server, etc.  We'd need an
> implementation of the underlying data objects that could talk to this user
> database and satisfy the interfaces, and that should be all you'd need.
> Making it performant enough for the core is just an engineering exercise
> .
> 
> -Barry
> 
> [1] Whether any of this works or has the right separation is another matter
> entirely. ;)  For example, looking at it now, I'm not so sure Members
> shouldn't be part of the MailingList pillar rather than the user database
> pillar.
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 8:25 PM, Stephen J. Turnbull  wrote:

> Richard Wackerbarth writes:
> 
>> Since we consider the user manager to be a part of the MM complex,
>> what have we gained by hiding the underlying credential from the
>> web interface?
> 
> Security.  See the OAuth 2.0 spec (RFC 6749) which recommends (at
> SHOULD level) this practice.

RFC 6749 addresses the implementation of an OAuth authorization system.

In this context, SHOULD refers to the implementation of this RFC.

It does not imply that other authorization schemes also need to meet those same 
criteria.

As for security, exposing the authorization server to direct Internet access 
is, in itself, a security weak point.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

What I am suggesting is that we use the JSON format and URLs that are generated 
by this combination.
If you later decide to implement it in a different framework, you can still use 
the same external representation.

On Apr 18, 2013, at 4:33 PM, Florian Fuchs  wrote:

> 2013/4/18 Richard Wackerbarth :
>> Yes, yes. Please re-invent the wheel once again.
>> 
>> And while you are at it, you might just remove the dependancies on zope and 
>> storm, etc.
>> 
>> I think that you are missing the point that, at this time, this is intended 
>> to provide the capabilities that MM-core chooses not to implement.
>> Those website components (HK and Postorius) are being driven by Django and 
>> you only make it more difficult to implement them when choose a different 
>> schema to model/present the data.
> 
> I don't want to re-invent the wheel and I don't advocate dismissing
> Django. Django is probably perfect for the prototype. It might also be
> perfect for the final thing. But we don't know what database we're
> gonna use in the end (which determines if the Django ORM still fits),
> or if we'll use many HTML templates etc. If we end up not using many
> of the things that make Django great, we might wanna think about if we
> want to use it. And might still come to the conclusion that we do. All
> I'm saying is: The environment for such an app could be a little
> different to Postorius/HK, so let's spend some thought on it. Is this
> such a bad idea?
> 
> Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 1:54 PM, Florian Fuchs  wrote:

> 2013/4/18 Richard Wackerbarth :
>> Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona, 
>> kerberos, etc.) were protocols whereby one system (the provider) furnishes 
>> credentials for a second system (the client) to some third system (the 
>> consumer).
>> 
>> By configuration, the consumer trusts that the provider has verified the 
>> client's identity and furnished appropriate credentials.
>> Thus, when the client presents credentials in an interaction with the 
>> consumer, the consumer provides services on the basis of the credentials.
>> 
>> If we assume that we distribute the MM implementation to include more than 
>> the two (core and web UI) systems by having, for example, a user manager, 
>> there might be an argument for passing around such credentials.
> 
> I was primarily thinking about the (future) authenticated REST API in
> Postorius. In that scenario a third party web app that we don't know
> would request an access token from the user profile store (provider)
> as well a user's email address. It would then use that access token
> for requests to the Postorius API (consumer).
> 
> If the instance of the user store does not act as provider, we would either:
> 
> 1) effectively require every api user to have an account with some
> other oauth provider.
> 
> or
> 
> 2) use some other authentication method.
> 
> 
> 1) is odd in my opinion. Mailman is free software. And there are not
> too many oauth providers that match that philosophy.
> 2) would be totally great if we found something that doesn't require a
> user to provide his credentials to said 3rd party app.

Look at what happens now.  The user contacts Postorius and presents either some 
oAuth/BrowserID-style credential or it presents a username/password. In 
exchange, Postorius issues a local credential (session key).

When the username/password path is chosen, Postorius acts as an agent for the 
user and verifies the login. In this case, Postorius must "see" the underlying 
credential (username/password pair) to be able to present it to the 
authenticator.  In the oAuth path, Postorius never sees the underlying 
credential, but exchanges the presented one for its local credential.

Since we consider the user manager to be a part of the MM complex, what have we 
gained by hiding the underlying credential from the web interface?

Therefore, I would suggest that we need to be able to accept third-party 
(oAuth) credentials and also locally presented ones.
I don't see where we gain an advantage by exposing the authenticator as a 
separate oAuth provider.


> I don't know. Maybe I'm missing something. And of course I agree with
> Stephen: If it's too hairy in terms of security, we should not do it.
> 
> Anyway, we're talking about something that is absolutely not needed
> for what we want to achieve *right now*, which is a profile data store
> that Postorius/HK/etc can access from localhost (or maybe from an
> internal network. Or IP-restricted through SSL. Or... ?).
> 
> Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Yes, yes. Please re-invent the wheel once again.

And while you are at it, you might just remove the dependancies on zope and 
storm, etc.

I think that you are missing the point that, at this time, this is intended to 
provide the capabilities that MM-core chooses not to implement.
Those website components (HK and Postorius) are being driven by Django and you 
only make it more difficult to implement them when choose a different schema to 
model/present the data.

On Apr 18, 2013, at 2:29 PM, Florian Fuchs  wrote:

> 2013/4/18 Richard Wackerbarth :
>> On Apr 18, 2013, at 1:19 AM, Florian Fuchs  wrote:
>>> 3) It doesn't need Django.
>>> Since it will not deliver any HTML (except an oAuth login form -- see
>>> 5.) and it doesn't need to be integrated into any existing web site,
>>> we can choose a more light-weight framework.
>> 
>> Here I take exception. Dismissing Django is a restriction that unnecessarily 
>> affects the ease of implementation and, in the common case, complicates the 
>> integration of the functionality.
>> 
>> Although it could be implemented without Django, it could also be 
>> implemented as a Django "app".
>> An instance of a django server can then serve the functionality.  As an 
>> alternative, where appropriate, this "app" would directly "drop in" to an 
>> instance of Postorius or an enterprise website.
>> 
>> One of the advantages of Django is that it can be used as a rapid 
>> prototyping mechanism. Simplified interfaces to the data are "free" and more 
>> elaborate ones can be added in an incremental fashion.
>> Also, rather than writing custom modules for things such as authentication 
>> and REST interfaces, there is the large community of third-party extensions 
>> which readily integrate to provide that functionality.
> 
> It's not that I don't want to use Django. I just wanted to point out
> that we won't need much of it for a pure JSON API. OTOH adding a new
> dependency by using another framework is probably not a good idea
> either. So if we want to keep the number of dependencies low, the
> alternative would probably be to use no framework at all and use
> restish for the, well, REST stuff (or whatever library the core will
> be using in the future).
> 
> Florian
> 
>> I would advocate that this "User" module make it appear as if stores the 
>> entire "record" for the user.
>> In the implementation, it could actually store parts of the user information 
>> in multiple databases (one of which could be the MM-core).
> 
> +1

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 2:39 PM, Florian Fuchs  wrote:

> 2013/4/18 Terri Oda :
>> We're probably going to be running around with a bit of a hack job for the
>> user database in the near future (either done by a student who needs it in a
>> hurry or done by one of the core devs to support a student who needs it in a
>> hurry) so while I don't like to design on the assumption it's going to go
>> wrong, I think in this case planning for a redesign might be prudent because
>> it's pretty clear we don't actually know all our requirements.
> 
> I think in this case it makes sense to spend a more time on the API as
> seen from the outside (urls, methods, json responses) than the actual
> implementation. If the API is good, it's totally acceptable if the
> underlying implementation will be redesigned later.

I agree and I would advocate that that API model be based on the interface that 
you can readily get from
a django database model and the django-rest-framework.

There is a big advantage to being able to readily edit the model and have the 
corresponding changes to the interface automatically generated. Since HK and 
Postorius already use Django, you are not adding any significant dependancies. 
And you can leverage a existing code base for the implementation details.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 11:26 AM, Terri Oda  wrote:

> On 13-04-18 8:03 AM, Richard Wackerbarth wrote:
>> On Apr 18, 2013, at 1:19 AM, Florian Fuchs  wrote:
>> 
>>> 1) It should be self-contained.
>>> Meaning: It should not depend on any
>>> mailman/mailman.client/postorius/hyperkitty packages.
>> Agreed
> 
> I agree about not needing postorious/hyperkitty, but I think a case could be 
> made that interdependence with mailman core and mailman client might make 
> sense.

Clearly, if you are going to follow (2) below, you will need to interface to 
MM-core for the portion that is stored there.

>> I would advocate that this "User" module make it appear as if stores the 
>> entire "record" for the user.
>> In the implementation, it could actually store parts of the user information 
>> in multiple databases (one of which could be the MM-core).
>> 
>> This would also allow the option of having the MM-core become a client of 
>> this User module, just as it now relies on an external message store.

Notice that I indicate that this is an option.  Although, in the long run, I 
think it is the right way to go, getting there can be a migration and not 
something that needs to happen all at once.
> 
> Two options occur to me:
> 
> 1. The user module is what mm-core uses for all user stuff.
> 
> I thinks case, case we have to be *much* more conservative about 
> dependencies.  I think Django would be right out as a dependency for Mailman 
> core, for example.

I thought that we were viewing this as a service accessed through a REST 
interface. MM core need never know if it is implemented using Django or FORTRAN 
or ...

Why is depending on some part of Django prohibited when core uses zope, storm, 
... ?
Dependencies are just dependencies. As long as they are stable and readily 
available, why not use those that are useful?

>  Plus, we're going to have to care a lot more about speed and all.

Much of the user information is not needed in the message handler (where speed 
is a consideration).

Functions such as administration-by-mail that need to access the information 
are much less critical.
Further, I will argue that those functions should be factored out of the "core" 
and exist as separate components.

> 2. The user module reads from mm-core and augments it.
> 
> This gives us the ability to supplement mm-core without impeding speed.  We 
> discussed possibly filling in the blanks with respect to things like the user 
> preferences (which are currently set by membership, by user and by email 
> address... but a lot of those return an empty set when queried if nothing is 
> set directly there...) so this is maybe something we already want.
> 
> Conceptually, #1 is probably easier because everything will be in one place, 
> but if we do #2 right, we can make it just as conceptually easy for 
> HyperKitty/Postorius/etc. without impeding Barry's core dev at all.  That 
> does mean in case 2 that Mailman Extraneous User Stuff is going to depend on 
> Mailman Core, though.
> 
> My preference is #2:

I would agree except to the extent that Postorius references the user 
information.
I believe that all user data should be accessed from the same source. I 
consider it poor design for the consumer of data to have to keep track of where 
particular parts of the data are stored.

> a) It doesn't add any dependencies to Mailman core.
> b) It doesn't require big changes in Mailman Core.  Given that core is pretty 
> much ready to release, now would be a bad time for changes, and I'm just not 
> sure we can justify that amount of work for the types of features that will 
> be built on the extraneous user stuff.
> c) It will be much easier to rip this out and replace it when we better 
> understand our actual needs.   (e.g. Right now, I think a case could be made 
> that a quick mock-up in django would be fine, but I suspect that requiring 
> django for some potential applications would border on ridiculous)
> 
> We're probably going to be running around with a bit of a hack job for the 
> user database in the near future (either done by a student who needs it in a 
> hurry or done by one of the core devs to support a student who needs it in a 
> hurry) so while I don't like to design on the assumption it's going to go 
> wrong, I think in this case planning for a redesign might be prudent because 
> it's pretty clear we don't actually know all our requirements.
> 
> Terri
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 12:21 PM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:
>> On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull"  
>> wrote:
>> 
>>> Richard Wackerbarth writes:
>> 
>>>> There is no reason why alternate channels [to a connection from
>>>> localhost authorized by the OS] cannot be substituted as long as a
>>>> means of identification (such as shared secrets) is utilized.
>>> 
>>> Sure, but didn't you notice the elephant in the room as you swept it
>>> under the rug?  The implementation of "alternate channels" matters *a
>>> lot*, and it's not trivial.
>> 
>> Just because something is important or non-trivial to implement
>> properly does not imply that it is difficult for us to utilize it.
>> Rather than developing our own, we can, and should, leverage the
>> efforts of "the professionals" and use the tools that they provide
>> (such as https and oAuth, etc.).
>> 
>> Certainly, the proper administration of each, and every, host is an
>> essential element to prevent access "on the coat tails" of the
>> trusted agents. But that also applies to the "localhost"
>> implementation.
> 
> I don't understand what you're advocating, your comments are way too
> general.
> 
> My position is that secure authentication and authorization is a hard
> problem, and we should avoid doing that as much as possible (partly
> because as far as I know none of us are experts).  No channels that
> few sites will use, ditto OAuth providers.  Concentrate on a couple of
> channels with specific, well-understood, universal (or at least very
> common) use cases.
> 
> The channels I have in mind are (1) shell access, (2) Basic Auth over
> HTTPS for people who need to control access fairly tightly, and (3)
> OAuth and/or Persona clients allowing authentication by any of a
> number of public providers for user (especially subscriber)
> convenience.  I'm not wedded to any of those (except (1), for obvious
> reasons), but I don't think it's a good idea to extend the list if we
> can avoid it.

Perhaps I didn't understand you.  I thought that you were advocating the 
omission of any channels other than "shell" and "localhost".
I was trying to point out that HTTPS, oAuth, etc. should be equally viable (and 
they don't REQUIRE that the components reside on the shame host).
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:
> 
>> Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and
>> persona, kerberos, etc.) were protocols whereby one system (the
>> provider) furnishes credentials for a second system (the client) to
>> some third system (the consumer).
> 
> That's correct.
> 
>> If we assume that we distribute the MM implementation to include
>> more than the two (core and web UI) systems by having, for example,
>> a user manager, there might be an argument for passing around such
>> credentials.
> 
> But the does provide a user manager, and the "extra profile info" is
> in fact intended to be a user manager external to the core.
> 
>> Thus, although we need some level of authentication of the agent,
>> there is no need for third party credentials such as those
>> implemented in oAuth.
> 
> The point is that in many cases we would like to dispense with the
> agent authentication process altogether, and let a third party manage
> that.  This is perfectly acceptable in the case of open subscription
> lists where we simply want to ensure that only the subscriber can
> change their subscriptions.  For example, a person subscribing a Gmail
> account to use that account's credentials rather than creating new
> owns inside of Mailman -- which we trust only because the person
> demonstrates in a roundabout way that they can access that mailbox.
> OAuth allows us to make that check directly in real time.

I have no problem with, and actually encourage, that we act as a consumer of 
oAuth credentials.
However, the issue here is whether we should be provider of oAuth credentials 
(which might then be presented to some outside, totally unrelated, entity.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 11:42 AM, "Stephen J. Turnbull"  wrote:

> Richard Wackerbarth writes:

>> There is no reason why alternate channels [to a connection from
>> localhost authorized by the OS] cannot be substituted as long as a
>> means of identification (such as shared secrets) is utilized.
> 
> Sure, but didn't you notice the elephant in the room as you swept it
> under the rug?  The implementation of "alternate channels" matters *a
> lot*, and it's not trivial.

Just because something is important or non-trivial to implement properly does 
not imply that it is difficult for us to utilize it.
Rather than developing our own, we can, and should, leverage the efforts of 
"the professionals" and use the tools that they provide (such as https and 
oAuth, etc.).

Certainly, the proper administration of each, and every, host is an essential 
element to prevent access "on the coat tails" of the trusted agents. But that 
also applies to the "localhost" implementation.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

On Apr 18, 2013, at 1:19 AM, Florian Fuchs  wrote:

> Hi,
> 
> some first thoughts on it:
> 
> 1) It should be self-contained.
> Meaning: It should not depend on any
> mailman/mailman.client/postorius/hyperkitty packages.

Agreed

> 2) Like the core, it should implement a Python-based webserver.
> It doesn't need to run on Ports 80/443, so we don't have to care about
> one of the popular web servers already listening to those ports.
> Also, we definitely don't want admins to have to follow another "how
> to setup mailman.users with Apache/mod_wsgi" howto.
> It should just run if someone says "start" (Maybe it can even hook
> into $ bin/mailman start? I know, that contradicts item 1. ...).

Where it runs is something that should be easily configurable as a part of 
installation.
To simplify installation, I would advocate that all of the MM subsystem 
interfaces become self-documentating.
By doing so, much of the configuration could be done through a "discovery" 
mechanism.

That would provide an easy way to have modular plug-in extensions.
It would also provide a way for Postorius to automatically adapt to the 
addition of configuration settings or user fields.

> 3) It doesn't need Django.
> Since it will not deliver any HTML (except an oAuth login form -- see
> 5.) and it doesn't need to be integrated into any existing web site,
> we can choose a more light-weight framework.

Here I take exception. Dismissing Django is a restriction that unnecessarily 
affects the ease of implementation and, in the common case, complicates the 
integration of the functionality.

Although it could be implemented without Django, it could also be implemented 
as a Django "app".
An instance of a django server can then serve the functionality.  As an 
alternative, where appropriate, this "app" would directly "drop in" to an 
instance of Postorius or an enterprise website.

One of the advantages of Django is that it can be used as a rapid prototyping 
mechanism. Simplified interfaces to the data are "free" and more elaborate ones 
can be added in an incremental fashion.
Also, rather than writing custom modules for things such as authentication and 
REST interfaces, there is the large community of third-party extensions which 
readily integrate to provide that functionality.

> 4) Adding new content types for user records should be easy, but
> clearly defined.
> We don't know what information applications need to store. Icons,
> essays, avatars, IRC handles, Twiter names, ...
> So we might think about using a schema-less database, but: We don't
> want to make it possible to just manipulate the result JSON and POST
> it back to the resource, possible deleting things other apps need. So
> adding new information types should be a separate process.
> 
> 5) It should implement an oAuth provider.
> This could be used for API authenticaion and to log into
> Postorius/Hyperkitty (even on other servers. Hint: Reputation!)
> We won't need this for a first prototype though. For now we're
> probably fine with 6)
> 
> 6) Like the core it should be accessible with BasicAuth from localhost.
> Ideally, in the future, it should be accessible both via BasicAuth
> from localhost and via oAuth from the outside world...
> 
> Please correct me where I'm being stupid!
> 
> Florian

> 2013/4/18 Terri Oda :
>> Background for folk new to this discussion:
>> 
>> Currently, all user information is stored in Mailman core, but it's minimal:
>> a real name, a set of email addresses, subscription info, and preferences.
>> Barry suggests that it should stay minimal: only the things Mailman needs to
>> know to correctly deliver mail (which actually doesn't include "real name"
>> but let's leave that as a legacy item for the moment)

I would advocate that this "User" module make it appear as if stores the entire 
"record" for the user.
In the implementation, it could actually store parts of the user information in 
multiple databases (one of which could be the MM-core).

This would also allow the option of having the MM-core become a client of this 
User module, just as it now relies on an external message store.

>> It's pretty likely that future features of Mailman will want to attach extra
>> information to users.  Some of it will be social-y stuff like user icons for
>> HyperKitty to display in the archives. Other things include metrics like
>> "when did this person last post to the list?" or "how many posts have they
>> made over the lifetime of this list?"  One thing I know of is that Systers
>> requires a short essay for all new subscribers, explaining why they want to
>> join the list.   (And they're considering porting this feature to Postorius,
>> which means we potentially want an answer to "where will the extra profile
>> data get stored?" before their students start coding.)
>> 
>> So...
>> 
>> I think we've sort of agreed that it would be best if whatever we built just
>> had a rest interface and hyperkitty/postorius/whatever would talk to it
>> thr

Re: [Mailman-Developers] Architecture for extra profile info

[Richard Wackerbarth]

Whoa! Perhaps I don't understand oAuth. I thought that oAuth (and persona, 
kerberos, etc.) were protocols whereby one system (the provider) furnishes 
credentials for a second system (the client) to some third system (the 
consumer).

By configuration, the consumer trusts that the provider has verified the 
client's identity and furnished appropriate credentials.
Thus, when the client presents credentials in an interaction with the consumer, 
the consumer provides services on the basis of the credentials.

If we assume that we distribute the MM implementation to include more than the 
two (core and web UI) systems by having, for example, a user manager, there 
might be an argument for passing around such credentials.

However, the design that has been followed thus far does not have the client 
communicating directly with the consumer system. Instead, the web UI interacts 
as an agent for the client. In this model, we have implicitly trusted the agent 
to properly represent the client and also screen client requests in accordance 
with system policy. Thus, although we need some level of authentication of the 
agent, there is no need for third party credentials such as those implemented 
in oAuth.

A connection on "localhost" is a form of credential. Trusting that the OS 
design restricts access to the connection, and trusting the applications 
running on that host provides a level of identification and trust.

There is no reason why alternate channels cannot be substituted as long as a 
means of identification (such as shared secrets) is utilized.
In those cases, the security of the communication channel and the 
trustworthiness of the agent system need to be considered. However, in a 
logical sense, the interaction is the same as one using the localhost channel.


On Apr 18, 2013, at 4:27 AM, Florian Fuchs  wrote:

> 2013/4/18 Stephen J. Turnbull :
>> Florian Fuchs writes:
>> 
>>> 5) It should implement an oAuth provider.
>> 
>> I don't see this.  Mailman is an auth consumer.  The only people
>> Mailman can provide auth for are the site admins.  Everybody else is
>> more or less untrustworthy.
>> 
>> I can see that there are applications where it would be useful to have
>> an auth provider bundled with Mailman, but I think implementing it is
>> somebody else's job.
>> 
>>> This could be used for API authentication and to log into
>>> Postorius/Hyperkitty
>> 
>> I think generic auth provider is overkill for these purposes, and a
>> trap for anybody who thinks we know enough about crypto/security to do
>> this stuff well.
> 
> I agree it's probably not easy. And, yes, maybe we need someone to
> help us with that.
> 
> But maybe we can take a moment to think about the usefulness of such a
> feature and the possibilities this might open up, rather than
> dismissing the use of a certain technology right off the bat. If we're
> unsure we can implement this in a secure way, we can still say no to
> this. Also, who says such a feature would be enabled by default? We
> can add it as an "experts only" thing and leave it up to the admins to
> make sure they use it in a secure environment.
> 
> I remember several discussions during PyCon(s) and on IRC where
> scenarios of different mailman instances talking to each other came
> up. Of course that doesn't mean implementing  a generic oAuth provider
> is the only answer to this. If there are better and easier solutions,
> fine.
> 
> Luckily going beyond localhost isn't something we need for the
> prototype that Terri suggested to be built for GSoC.
> 
> Florian
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC 2013 project discussion

[Richard Wackerbarth]

In evaluating a proposal, we need to look at a number of factors:

First, will it work? -- Does the proposed design accomplish the stated 
objective?
Next: Is it useful?
And: Can the candidate be expected to accomplish the task within the allotted 
time frame?
Finally: Is it the best use for our limited resources (funding, mentor time, 
etc.)?

If your presentation makes it easier to answer each of those questions in a 
positive manner, it will increase the likelihood that it will get funded.


On Apr 17, 2013, at 6:16 AM, Avik Pal  wrote:

> for identifying an important message a classifier will be implemented. and 
> thanks for pointing out the issue regarding the delivery of the message, if 
> it is delivered twice then the existing implementation of delivery is 
> sufficient, but if we want to deliver it only once then for each person we 
> need to maintain a database of important mails/threads to him(or vice-versa) 
> and while sending check against that database. but this is going to raise 
> some normalization issues which are to be taken care of by careful designing.
> 
> Avik Pal
> Bengal Engineering & Science University,Shibpur
> github:https://github.com/avikpal
> IRC:- irc://freenode/avikp,isnick
> twitter:-https://twitter.com/avikpalme
> 
>   
> 
> 
> 
> On 17 April 2013 01:02, Richard Wackerbarth  wrote:
> An interesting suggestion -- A couple of things to consider:
> 
> How do you identify "important" messages?
> 
> Will you deliver these messages twice -- first as important and then, later, 
> as a part of the digest ?
> 
> 
> On Apr 16, 2013, at 2:13 PM, Avik Pal  wrote:
> > also I would like to propose an idea of my own. Many of us set the
> > preference in mailman to get all the emails of a day batched together, but
> > sometimes this means we miss important mails(though we get it at the end of
> > the day but we miss the moment)important to the community, or my own
> > interest, discussion on something I also have discussed upon in my previous
> > mails, delivery of these mails instantly to the subscriber so that he can
> > also join at that very moment may come out to be a very useful feature.
> > Thus person gets to set two options
> >1.receive batched mails only.
> >2.receive batched mails with important mails delivered instantly.
> 
> 

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC 2013 project discussion

[Richard Wackerbarth]

An interesting suggestion -- A couple of things to consider:

How do you identify "important" messages?

Will you deliver these messages twice -- first as important and then, later, as 
a part of the digest ?


On Apr 16, 2013, at 2:13 PM, Avik Pal  wrote:
> also I would like to propose an idea of my own. Many of us set the
> preference in mailman to get all the emails of a day batched together, but
> sometimes this means we miss important mails(though we get it at the end of
> the day but we miss the moment)important to the community, or my own
> interest, discussion on something I also have discussed upon in my previous
> mails, delivery of these mails instantly to the subscriber so that he can
> also join at that very moment may come out to be a very useful feature.
> Thus person gets to set two options
>1.receive batched mails only.
>2.receive batched mails with important mails delivered instantly.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] anti-spam filter

[Richard Wackerbarth]

FWIW,

I tend to support Stephen's view with respect to usefulness and interface 
strategy.

Wacky

On Apr 15, 2013, at 5:22 AM, Stephen J. Turnbull  wrote:

> Patrick Ben Koetter writes:
> 
>> Perhaps the integration could create an interface itself that makes
>> it easy to add other filters in the future. I am thinking Postfix
>> 'content filter', which uses SMTP/LMTP to send messages to an
>> external filter and they send it back then using SMTP.
>> 
>> The first Mailman content filter could be the one you
>> proposed. Others could add their filter later.
> 
> I don't see any Mailman-specific issues in content-based spam
> filtering, though, and very little Mailman-specific coding.  I also
> worry about reinventing the wheel, with corners.  Ie, why do we think
> a GSoC student is going to be able to do something that's worth
> putting up again the very effective filters with huge user bases like
> SpamAssassin and SpamBayes that are already out there?  Wouldn't a
> half-baked summer project just sit there and bitrot?
> 
> OTOH, a generic interface to the Mailman REST API, which could be used
> by Sendmail milters or whatever else is out there and somewhat
> standard (is it Postfix or Exim that can handle milters? I forget),
> with example implementation of a milter that checks whether the poster
> is subscribed by asking Mailman, would be useful as an extension to
> any MTA used with Mailman.
> 
> Or Terri's through-the-web interface to the Mailman Handler
> pipeline(s), with an example Handler installable from PyPI which wraps
> SpamAssassin or SpamBayes.
> 
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/rkw%40dataplex.net
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Hi from a student interested in a GSoC project

[Richard Wackerbarth]

I encourage any GSoC candidates to actively discuss design issues on this list. 
Many aspects of MM3 remain only partially defined and still require design in 
addition to the coding that will follow. Although some might expect the mentors 
might "spoon feed" coding tasks, as a mentor, I would prefer to work with 
someone who is actively involved in the design as well as the implementation.

Having looked at MM2->MM3 migration in the past (and deferred implementation 
because critical infrastructure was not available at that time) let me present 
a different perspective.

First, there are some parameters that do not relate to any particular mailing 
list.
IMHO, these aspects need not even be addressed in a conversion.
If I wish to set up a MM3 installation, I should first, manually, set up a 
sample list.
After I do so, the configuration of any "real" lists needs to be COMPLETELY 
configurable using the REST interface. If that interface is not presently 
adequate, it needs to be revised rather than "working around" any deficiency.

Therefore, I should be able to set up my "sample list" and, thereafter, 
add/edit all of the real lists utilizing the same interface (using 
mailman.cliient, etc.) that is available to the Postorius interface for list 
creation/editing. A migration tool would, therefore, need only "simulate" those 
manual steps that the installer would execute on a web-based interface to 
create a new list and adjust its settings.

Similarly, handling the subscriptions must be something that can be done using 
just the access exposed via the REST interface.

The big distinction between MM2 and MM3 lies in the conceptual model of 
entities. In MM2, each subscription is a separate entity. In MM3, subscriptions 
belong to "persons" and management functions are made available for the person 
to affect multiple subscriptions at the same time.

In translating from MM2 to MM3, the aggregation of subscriptions under a common 
"person" becomes a non-trivial task.
However the mechanisms required to handle reassignment are needed within MM3 
implementations because there is an alternate access mechanism (admin by email) 
which cannot directly identify these "persons".

Therefore, I would suggest that a migration be broken into some components,
1) Migrate individual list parameters
2) Aggregate groups of lists
3) Migrate individual subscriptions
4) Aggregate subscriptions by "person".

Note that the aggregation functions for both lists and persons require similar 
mechanisms and that having the ability to edit those configurations within 
Postorius will be beneficial to both migration and routine system operation.

Richard


On Apr 11, 2013, at 3:11 PM, Barry Warsaw  wrote:

> On Apr 11, 2013, at 02:22 PM, Elias Assarsson wrote:
> 
>>> * MM2's configuration file is a Python file which really must be imported
>>> in order to get a valid set of values.  MM3's configuration file is a stack
>>> of .ini-style files.
> 
>> I am trying to find and understand the configuration files so that I know
>> what that that needs to be migrated and to what form. Is the MM2
>> configuration you refer to mainly Mailman/mm_cfg.py and MM3 configuration
>> files src/mailman/config/* and /src/mailman//*?
> 
> Yes, in a deployed Mailman 2, mm_cfg.py will contain the system configuration
> settings.  These override the settings from Defaults.py so a good way to
> explore is to use `bin/withlist` and `import mm_cfg` at the Python prompt.
> 
> In MM3, we use lazr.config, which is essentially a configparser type package
> that allows for stacks of configurations, with pushing and popping values on
> this stack.
> 
> http://pythonhosted.org/lazr.config/
> 
> The src/mailman/config/schema.cfg file is at the bottom of the stack and
> defines the schema, obviously :).  From there, src/mailman/config/mailman.cfg
> essentially instantiates this schema, providing all the defaults.  In the
> testing environment, src/mailman/testing/testing.cfg gets pushed on top of
> that (and many tests push and pop micro-overrides).  In a deployed system, the
> site's mailman.cfg is on the top of the stack and so can override anything.
> There are various places this mailman.cfg file is searched; see
> src/mailman/core/initialize.py for all the gory details.
> 
> List-specific configurations live in the various config.db files for MM2.
> These are pickles.  In MM3, everything's in the database.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Google summer of code 2013

[Richard Wackerbarth]

As has been suggested previously, at this point it is best that you simply 
start the discussion here on the mailing list.
All of the mentors read the list and technical discussions should involve the 
entire community.

On Apr 10, 2013, at 9:25 AM, Pratik Sarkar  wrote:

> I am interested to work in the "Anti-spam/anti-abuse" in the Mailman
> project for this year's Google summer of code.How can I contact the
> respective mentors?
> Regards,
> Pratik
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC 2013 - Introduction and Project Discussion

[Richard Wackerbarth]

Let me suggest that it would be useful to have the student develop something 
which could act as a plug-in module for any website. If we assume that there is 
an optional archiver such as hyperkitty, there should be a mechanism to "seed" 
the submission (in-reply-to, quoted text, etc.). But, if the archiver is not 
present, the same submission mechanism could handle submissions for any 
website, with or without postorius present.

The interface should address user authentication, using, when available, 
credentials that have already been provided. But it should also accept 
un-authenticated submissions and interact with the system to implement the list 
policies.

It should be interesting to see just what the students propose.

-- Richard

On Apr 8, 2013, at 7:42 PM, Terri Oda  wrote:

> On 13-04-08 5:27 PM, Stephen J. Turnbull wrote:
>> Pierre-Yves Chibon writes:
>>  > On Sat, 2013-04-06 at 15:03 +0530, Udit Saxena wrote:
>>  > > 2. Web Posting Interface.
>>  >
>>  > Isn't this similar/overlapping to what HyperKitty already does?
>> 
>> No.  There's no reason why a web posting interface needs to interact
>> with the archives; it can talk directly to Mailman core, and will need
>> to do so for other features such as authentication, sister lists, and
>> the like.  You get archiving for free.
> 
> I think Stephen covered most of it, but I just want to add that I had in mind 
> that if we do the separate posting interface right, we might be able to use 
> this as the beginnings of a way to integrate any existing forum software into 
> Mailman, much like we want to gateway from newsgroups.
> 
> That said...
> 
> I'm totally ok with this particular project being entirely part of hyperkitty 
> in the short-term, though, since it'll clearly be a nice fit there right now 
> and goodness knows I don't want to deal with yet another django-standalone 
> instance running just to post messages. ;)   The only reason I didn't suggest 
> this be part of hyperkitty in the project description is that when I was 
> writing up project information, I didn't know if any of the hyperkitty team 
> would have time to mentor.  If one of the hyperkitty devs wants to take the 
> lead on mentoring this project, that would work for me!
> 
> Terri
> 
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC 2013 - Introduction and Project Discussion

[Richard Wackerbarth]

Well, the Django ORM does run on python 3. So, even if it isn't "the best", it 
is a possibility.

Richard

On Apr 8, 2013, at 1:34 PM, Barry Warsaw  wrote:

> On Apr 08, 2013, at 07:02 AM, Richard Wackerbarth wrote:
> 
>> Although we would like for MM3 to run on Python 3, I don't think that all of
>> our dependency libraries are ready for that yet.  I am running MM under
>> Python 2.7
> 
> We're down to two dependencies: restish and storm.  I took a crack at restish,
> but got stuck.  At Pycon, Thomi and I talked about another approach, and he
> was taking another stab at it, but I haven't talked with him about since then.
> 
> I suspect storm will never get ported.  I've said before that if that's the
> last dependency, we'll switch, probably back to SQLAlchemy as that's the only
> Python 3 compatible ORM I'm aware of.
> 
> Help certainly wouldn't be turned down. :)
> 
> -Barry
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC 2013 - Introduction and Project Discussion

[Richard Wackerbarth]

Although we would like for MM3 to run on Python 3, I don't think that all of 
our dependency libraries are ready for that yet.
I am running MM under Python 2.7

Richard

On Apr 8, 2013, at 3:13 AM, Udit Saxena  wrote:

> -- Forwarded message --
> From: Udit Saxena 
> Date: Mon, Apr 8, 2013 at 1:42 PM
> Subject: Re: [Mailman-Developers] GSOC 2013 - Introduction and Project
> Discussion
> To:
> 
> 
> I'm having problems installing the environment. From the 5 minute guide
> installation page:
> http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running
> 
> my  "bin/buildout" from the mailman folder is not able to run. bootstrap.py
> runs fine. But I don't know how to go further.
> The error says: Exception: failed to run command : "usr/bin/python3.3",
> "/tmp/tmpoe01dx", "-q","develop", "-mxN"
> 
> The same error occurs with python3 as well.
> 
> Please help.
> 
> 
> On Mon, Apr 8, 2013 at 7:48 AM, Terri Oda  wrote:
> 
>> 
>> On 13-04-06 3:33 AM, Udit Saxena wrote:
>> 
>>> 1. Authenticated REST-API in Postorius/Django
>>> 2. Web Posting Interface.
>>> 
>>> And OpenPGP integration is something I would really interested in learning
>>> about but have no prior experience or knowledge about how to go about it.
>>> 
>>> Can you guys guide me to someone who is overlooking these projects ? I
>>> would like to ask a few questions.
>>> 
>> 
>> We haven't actually parcelled out the projects to specific mentors at this
>> stage, and we prefer to keep the whole community involved in discussions as
>> much as possible, so please ask all questions directly on the list!
>> 
>> Terri
>> 
>> 
> 
> 
> -- 
> ---
> Udit Saxena
> Student, BITS Pilani,
> +917891400270
> 
> 
> 
> 
> -- 
> ---
> Udit Saxena
> Student, BITS Pilani,
> +917891400270
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] GSOC 2013 : Authenticated REST-API in Postorius/Django

[Richard Wackerbarth]

Welcome to our community,

I'm happy to see that you are interested in the REST interfaces.
In addition to TastyPie, I suggest that you also look at django-rest-framework.
Please compare the two and let us know what you see as the advantages and 
disadvantages of each.

Richard

On Mar 28, 2013, at 4:02 PM, Rahul Gaur  wrote:

> Hello,
> 
> I have been searching for Python/Django projects for a while and I
> stumbled upon the Mailman ideas page today.
> I am very much  interested in discussing more about the *Authenticated
> REST-API in Postorius/Django *and I hope to work on it over the summer *, *but
> let me first introduce my self.
> 
> I am into third year of my engineering (Computer Science) and I have been
> using Python since my first year and for the past couple of months I have
> been using Django for experimental projects at college and for a interest
> based social networking site(initially started from pinax).
> 
> I have already cloned the Mailman code base and it's up and running , I
> will go through the source code in next couple of days.
> 
> I haven't implemented RESTful API's before , but I have started learning
> more about REST and HTTP protocols  already and I hope that I would be in a
> better state by the time GSOC starts.
> 
> At the moment I am experimenting with the Django Tastypie and I have been
> wondering if the developers community here have been considering it or
> anything similar to it ?
> 
> I would like to get more involved with this project , if this is something
> community is seeking currently .
> 
> Please advice, how can I proceed.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Starting prep for GSoC 2013

[Richard Wackerbarth]

Terri,

In reference to your questions below, I offer these comments:

(a) I enjoyed mentoring last summer and would like to do so again.
(b) We need to give this serious thought, particularly if we were to propose 
direct participation (rather than under the PSF umbrella). One of the 
weaknesses of MM3 as a GSoC project is a lack of design maturity in terms of 
the intercommunication structure between components of a distributed 
implementation. This causes the student to need to be more involved in design 
aspects rather than just coding. Some students would be up to the task, but 
others might be overwhelmed by the lack of a complete design structure. We need 
to identify (1) some "trivial" introductory tasks, (2) projects appropriate for 
GSoC that are already clearly designed, and perhaps (3) projects that still 
need design. If we consider a student for this third category, we need to not 
only make sure that the student understands to complexity of the task, but 
establish metrics that can be used to evaluate student performance.
(d) As a part of the student "proposal", I think that we need to have the 
students submit a "portfolio" of prior work which we can evaluate for aspects 
such as clear and consistent coding, unit testing, etc. At least some of this 
code should be written in Python (unless the student proposal would be 
implemented in another language). Potential applicants could be directed to the 
"trivial" tasks that I mention above as a source of material to augment their 
portfolio if they do not already have an adequate presentation.

Richard

On Jan 9, 2013, at 2:09 PM, Terri Oda  wrote:

> Happy new year, all!
> 
> Although this year's GSoC hasn't actually been announced yet, now's a good 
> time for us to start figuring out what we as an organization want to do.
> 
> So here's some questions to get us started:
> 
> (a) Who would like to mentor for GSoC 2013?
> 
> I'm hoping all of you who participated last year are interested in doing it 
> again, and I'm happy to take on a few more mentors if there's anyone new 
> who'd like to help out.
> 
> (b) What projects do we have that would be appropriate for students?
> 
> Generally we give students new features and wishlist items -- if someone has 
> time to do a quick scan of the bug queues for Mailman/postorius/hyperkitty 
> and suggest a list that would totally be awesome.
> 
> (c) What intro documentation do we need to make it easy for students to get 
> ramped up?
> 
> I'd like to see:
> - overview architecture documentation (probably drawn from Barry's book 
> chapter/pycon talk)
> - an updated "getting started" (basically the 5-minute guide expanded for 
> less experienced developers)
> - a VM image with everything set up for people to try (preferably Ubuntu)
> 
> Anything else you'd like to see?  Anyone want to offer to start on any of 
> these?  The VM image shouldn't be to hard to set up.
> 
> (d) What do we want student proposals to look like?
> 
> We talked last year about how we'd like to have a more consistent proposal 
> format for students to follow; can one of our more experienced admins write a 
> proposal template & guidelines that we can have ready?
> 
> 
> Terri
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] HyperKitty : VCS change

[Richard Wackerbarth]

I understand that. However, your intentions do not keep me from having a 
different desire.
Perhaps, at some time in the future, circumstances will be different and you 
might reconsider.

Richard

On Jan 9, 2013, at 9:20 AM, Barry Warsaw  wrote:

> On Jan 09, 2013, at 09:11 AM, Richard Wackerbarth wrote:
> 
>> I would like to see all of the MM related development migrate.
> 
> I have no plans to migrate the core off of Launchpad and bzr.
> 
> Cheers,
> -Barry
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] HyperKitty : VCS change

[Richard Wackerbarth]

Personally, I also prefer Git because the tools supporting bzr are not as well 
integrated into Mac OSX work environments.

Postorius is based on Django and it, as well as most of the 3rd-party 
extensions, utilizes git for a VCS.

In maintaining the source, AFAICT, bzr and git are functionally interchangeable 
and the hosting location for either VCS is an independent issue. Both have 
reasonable alternatives available.

I would like to see all of the MM related development migrate.

Richard

On Jan 9, 2013, at 8:46 AM, Aurelien Bompard  wrote:

> Hello Mailmaners,
> 
> The HyperKitty project was historically using Bazaar as it VCS, and
> was hosted on fedorahosted.org. An essential component was split off
> (KittyStore), which was initially source-controlled with Git and
> hosted on Github.
> I'm trying to bring back some coherence into this, and considering
> switching all the components to Git on fedorahosted.org.
> The reason for this choice is that me and the other two most frequent
> contributors are much more skilled with git than with bzr.
> 
> We're concerned however by the uncomfortableness it may cause you, the
> Mailman community, if/when you want to contribute to HyperKitty.
> Barry, Terry, Florian, would that be a problem ? Others ?
> Of course I'm ready to merge patches sent by email or bugtracker, but
> that's a little more friction.
> 
> It's not a "speak now or forever hold your peace" moment, but this
> unnecessary complexity is tiring day-to-day, so I'd rather sort that
> out quickly-ish.
> 
> Thanks !
> 
> Aurélien
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [Merge] lp:~sophron/postorius/create_users into lp:postorius

[Richard Wackerbarth]

Isn't the visibility of the list members a per_list policy setting?

In any case, we will need to have list administrators (who are not the 
superuser) be able to see the membership on their list.

I think that Postorius will require a better model for roles.


Richard

On Oct 25, 2012, at 3:19 AM, Florian Fuchs  wrote:

> Review: Approve
> 
> Hi George, 
> 
> thank you for your changes (and the bug reports)! I have just merged them to 
> the trunk. I only made some very small changes and additions (adjusted the 
> docstring in MailmanUserView, added the user icon, some PEP8 fixes...). I 
> also made the user list and details only available to superusers (I don't 
> think every user should be able to see who else is there...).

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Getting to Mailman 3.0 final

[Richard Wackerbarth]

On 09/18/2012 06:26 AM, Terri Oda wrote:
> That said, I'm tentatively planning a personal postorious hackathon all
> day Saturday the 22nd.  If anyone wants to join me, I'll be on #mailman
> on freenode!

Sorry that I cannot participate this weekend. I have another activity that will 
keep me busy from Friday afternoon through the weekend.

Richard
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Adding keys in the configuration file

[Richard Wackerbarth]

You had mentioned a reference to the Django settings for HK.
Even if HK is enabled, django should not get imported into the MM space.

The proper way to handle the issue of URLs would be to have the MM core query 
the UI for them.
However, I have yet to convince Barry that the present model (where, at 
present, MM is the only part allowed to be authoritative over ANY information 
that it uses) is inappropriate.
So, for the present, we need to have a proxy for the UI and a section of the 
configuration that specifies the values for the parameters which it supplies.

IMHO, we should actually treat it as multiple proxies so that we can handle the 
more generic configuration in a consistent manner.

On Sep 13, 2012, at 9:53 AM, Aurelien Bompard wrote:

> Sorry I messed up with a list-reply, so you people missed Richard's reply.
> 
>> What concerns me is that MM core should not depend on Django in order to run.
>> The Archive interface needs to accept the message and place it in the store.
> 
> MM won't depend on Django, only if the HK section in mailman.cfg is enabled.
> I can't just send the message to the store however, since the
> IArchiver interface also has methods to get the list and message's
> final archive URL, and that's dependent on the frontend. The store
> does not know how the frontend is installed (at the root URL, on
> /hyperkitty, on /archives, etc.).
> Those methods are run before the message is stored in order for their
> result to be added to the message headers, so I can't even get it from
> the archive_message call.
> 
> Aurélien

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Adding keys in the configuration file

[Richard Wackerbarth]

Why do you think that the configuration of HK should be a part of the MM core?
Like the Postorius configuration UI, HK is supposed to be a separable part of 
the overall system which is possibly running on an entirely separate host 
machine.
As such, its daemon would be configured and operated as a distinct service. The 
linkage between the two systems should be in the form of a single reference.

On Sep 13, 2012, at 2:19 AM, Aurelien Bompard wrote:

> Hi people,
> 
> I'm working on HyperKitty, and I've understood that I need to add this
> section to mailman.cfg to enable it :
> 
>  [archiver.hyperkitty]
>  class: hyperkitty.lib.archiver.Archiver
>  enable: yes
>  base_url: http://hyperkitty.example.com
> 
> That works well. However, I need another key to specify the location
> to HK's configuration file (Django's settings.py). I've tried simply
> adding the key, but it's not picked up by the configuration class,
> probably because of the schema validation.
> Is there a way I could add this configuration key ? Maybe via another
> section, or another file ?
> 
> Thanks !
> 
> Aurélien
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] 3.0.0b1 fails bootstrap.py on Mountain Lion

[Richard Wackerbarth]

In response to an inquiry concerning just what I did to get MM3 built yesterday:

First, I note that I have chosen to create two separate virtual environments 
for the installation. One is "postorius" which has the web interface, and the 
other is "mailman" into which I install just the mail-handling part.  I do this 
because these two components are logically separate and, by design, might be 
installed on separate host machines.

The mailman environment gets its sources from the lp:mailman repository. All of 
the other parts mentioned in the wiki installation guide go into the postorius 
environment.

The failure in the mailman installation (as of 6 Sep 2012) seems to result from 
a bad distribution package for z3c.recipe.tag, version 0.5.

After creating the mailman virtual environment, you can work around this by 
pre-installing this package before you run the (bootstrap/setup) for the 
mailman module.

Working in the virtual environment where you will install mailman:

First attempt to install z3c.recipe.tag
$ pip install z3c.recipe.tag

This will fail with a message like: (Note that I redacted part of the path. You 
should use the full path as reported on your own installation)
IOError: [Errno 2] No such file or directory: '/ ... 
/z3c.recipe.tag/CHANGES.txt'

Create that file
$ touch / ... /z3c.recipe.tag/CHANGES.txt

Now, try the installation again
$ pip install z3c.recipe.tag

This should succeed and you should then be able to complete the buildout of 
mailman.

Richard "Wacky" Wackerbarth

On Sep 6, 2012, at 10:38 PM, Barry Warsaw wrote:

> On Sep 06, 2012, at 10:23 PM, Richard Wackerbarth wrote:
> 
>> I have 10.7 and, today, I had the same problem.
>> 
>> Yesterday, I was able to set things up without any problems.
>> 
>> I think that the difference is that z3c.recipe.tag has bumped the version
>> number to 0.5 but that the distribution is missing one of its files.
> 
> Yep.  I sent a message off to zope-dev (the maintainer address in the
> setup.py) and distutils-sig (where buildout folks hang out).  I couldn't find
> a bug tracker for the package.  Let's hope a new version gets uploaded soon.
> 
>> By manually downloading the package, I was able to fake the missing
>> CHANGES.txt file and pre-install the module.
> 
> Nice workaround, thanks!

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] 3.0.0b1 fails bootstrap.py on Mountain Lion

[Richard Wackerbarth]

Greg,

First, let me address your choice of versions. Although the mail handling part 
of MM3 seems to be in pretty good shape, the Web UI still has quite a bit that 
hasn't been "fleshed out".  Traffic volume is not really a concern. If 
anything, the high traffic installations might be more inclined to prefer the 
MM3 architecture.

Depending on how much you need the Web UI, you may prefer to stick with MM2 
(unless you would like to help us finish parts of the Postorius interface).

As for "recreating" my work-around, I will provide additional details in 
response to the other sub-thread of this discussion.

- Richard "Wacky" Wackerbarth

On Sep 6, 2012, at 10:54 PM, G B wrote:

> Hey Richard—
> 
> How hard would it be to recreate your solution?  Could I bumble my way 
> through it with no Mailman, no Zope, and limited Python experience?
> 
> Maybe the first question I should ask is whether I should be trying the beta, 
> or if I should stick to the 2.x release.  I chose the beta to start with 
> because I don't expect this to be a high traffic system and I'd hoped to gain 
> the benefit of the new web interface and save the trouble of updating from 
> 2->3 later.
> 
> Thanks—
> Greg
> 
> 
> On Sep 6, 2012, at 8:23 PM, Richard Wackerbarth  wrote:
> 
>> Barry,
>> 
>> I have 10.7 and, today, I had the same problem.
>> 
>> Yesterday, I was able to set things up without any problems.
>> 
>> I think that the difference is that z3c.recipe.tag has bumped the version 
>> number to 0.5 but that the distribution is missing one of its files.
>> 
>> By manually downloading the package, I was able to fake the missing 
>> CHANGES.txt file and pre-install the module.
>> 
>> After that, the install worked just fine.
>> 
>> The Postorius install still needs some additional tweaking to make it work 
>> "out of the box", but it is progressing.
>> 
>> Richard
>> 
>> 
>> On Sep 6, 2012, at 9:05 PM, Barry Warsaw wrote:
>> 
>>> On Sep 06, 2012, at 11:11 AM, G B wrote:
>>> 
>>>> I initially posted this to mailman-users, but it was suggested that this
>>>> would be a better list.
>>>> 
>>>> I'm installing Mailman for the first time, and chose to try the beta.  I'm
>>>> installing on a Mountain Lion Server, that was cleanly installed.  I've 
>>>> since
>>>> updated the OS to 10.8.1
>>>> 
>>>> I got as far as 'python bootstrap.py' and it failed immediately with the
>>>> following traceback:
>>> 
>>> I don't have OS X 10.8 yet, but I tried it on my 10.6.8 machine, using
>>> MacPorts' Python 2.7.
>>> 
>>> I was able to bootstrap, but bin/buildout failed downloading one of the zc
>>> recipes.  I don't have much in /opt/local/lib/python2.7/site-packages and I
>>> didn't spend much time debugging the problem.
>>> 
>>> However, I was able to create a virtualenv and do a `python setup.py 
>>> install`
>>> into that virtualenv just fine.  I tested with `mailman info` but didn't try
>>> to much else.
>>> 
>>> I'm guessing it's something weird with 10.8's built-in Python 2.7.
>>> 
>>> Cheers,
>>> -Barry
>>> 
>>> ___
>>> Mailman-Developers mailing list
>>> Mailman-Developers@python.org
>>> http://mail.python.org/mailman/listinfo/mailman-developers
>>> Mailman FAQ: http://wiki.list.org/x/AgA3
>>> Searchable Archives: 
>>> http://www.mail-archive.com/mailman-developers%40python.org/
>>> Unsubscribe: 
>>> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
>>> 
>>> Security Policy: http://wiki.list.org/x/QIA9
>> 
>> ___
>> Mailman-Developers mailing list
>> Mailman-Developers@python.org
>> http://mail.python.org/mailman/listinfo/mailman-developers
>> Mailman FAQ: http://wiki.list.org/x/AgA3
>> Searchable Archives: 
>> http://www.mail-archive.com/mailman-developers%40python.org/
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/mailman-developers/g.c.b.at.work%40gmail.com
>> 
>> Security Policy: http://wiki.list.org/x/QIA9
> 
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] 3.0.0b1 fails bootstrap.py on Mountain Lion

[Richard Wackerbarth]

Barry,

I have 10.7 and, today, I had the same problem.

Yesterday, I was able to set things up without any problems.

I think that the difference is that z3c.recipe.tag has bumped the version 
number to 0.5 but that the distribution is missing one of its files.

By manually downloading the package, I was able to fake the missing CHANGES.txt 
file and pre-install the module.

After that, the install worked just fine.

The Postorius install still needs some additional tweaking to make it work "out 
of the box", but it is progressing.

Richard


On Sep 6, 2012, at 9:05 PM, Barry Warsaw wrote:

> On Sep 06, 2012, at 11:11 AM, G B wrote:
> 
>> I initially posted this to mailman-users, but it was suggested that this
>> would be a better list.
>> 
>> I'm installing Mailman for the first time, and chose to try the beta.  I'm
>> installing on a Mountain Lion Server, that was cleanly installed.  I've since
>> updated the OS to 10.8.1
>> 
>> I got as far as 'python bootstrap.py' and it failed immediately with the
>> following traceback:
> 
> I don't have OS X 10.8 yet, but I tried it on my 10.6.8 machine, using
> MacPorts' Python 2.7.
> 
> I was able to bootstrap, but bin/buildout failed downloading one of the zc
> recipes.  I don't have much in /opt/local/lib/python2.7/site-packages and I
> didn't spend much time debugging the problem.
> 
> However, I was able to create a virtualenv and do a `python setup.py install`
> into that virtualenv just fine.  I tested with `mailman info` but didn't try
> to much else.
> 
> I'm guessing it's something weird with 10.8's built-in Python 2.7.
> 
> Cheers,
> -Barry
> 
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

On Jul 17, 2012, at 6:38 PM, Barry Warsaw wrote:
> On Jul 13, 2012, at 07:34 PM, Richard Wackerbarth wrote:
>> But, that REST interface is only one implementation of the service interface.
>> The REST particulars are not really a part of the service.
> 
> I see what you're saying, and this 1000ft abstraction of the service may be
> useful in the sense that it's documentation for anyone else wanting to
> implement said service using a different IPC mechanism, but right now where
> the project is, this is a bit too abstract to be meaningful *to me*.  I have
> no problem with this kind of service description being defined before the user
> manager service is implemented, but it still has to be made more concrete one
> level down into an IPC protocol definition before it can be useful.

I think that you are finally beginning to understand the perspective that I am 
trying to provide.

Yes, to implement anything, we will need the concrete descriptions at the 
protocol level.
For example, we will need some definition of the services implemented as a 
RESTful interface.
Also, at least for the message handler, because you have chosen to implement it 
that way in Python, an object description such as ZCA for the implementation 
interface will be required.

However, and this is the reason that I object to the bypassing of the service 
level description, we also need to assure that each of these implementations 
respect the requirement that ALL inter-service interactions be representable 
strictly in terms of service-level interfaces. If you define only the 
implementation interface, then you have no standard upon which to judge 
adherence to any standard that does not REQUIRE ALL implementations to exactly 
duplicate all aspects of that particular implementation.

Specifically, one interface may provide multiple implementations which 
accomplish the same system service. (Many ways to skin the cat) Alternate 
implementations are required to provide just one of them.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Exposing not advertised lists via nntp archiver

[Richard Wackerbarth]

On Jul 17, 2012, at 1:46 PM, Barry Warsaw wrote:
> On Jul 17, 2012, at 01:34 PM, Richard Wackerbarth wrote:
> 
>> But there probably should be a per-list configuration option for gateway-ing
>> a list to the news.  There may well be lists for which I am willing to
>> advertise the existence without wanting their content to be spread far and
>> wide.
> 
> Agreed.  Some thoughts.
> 
> One is whether the mailing list is gatewayed to "Usenet" (really any external
> NNTP server).  We already have settings for this.

Then that should suffice for Alex's purposes. He should not have to "discover" 
that the gateway is active. If he gets a message on the archive service 
interface, he sends it out. If it doesn't appear, it wasn't meant to be.

> In an mm3 world where we can have multiple system-wide configured and enabled
> archivers, it probably makes sense to allow individual lists to opt-in or -out
> of specific available archivers.

Yes, this also allows George to collect metrics about messages without having 
the underlying messages archived. Or it also allows the messages to be archived 
without being counted by the metrics. It's all up to how our users choose to 
configure things.

>  We've talked about this before, and it's something I'm generally in favor of 
> allowing.

> The complication is that the system may want to force individual lists to 
> enable certain archivers.
> E.g. if the site administrators want to keep a local maildir of all messages 
> to all mailing lists.

This is a more general question concerning just how the configuration service 
enforces site policies.

On an implementation level, it gets mapped so that, to each of the various 
message handling services, each list has its own full set of configuration 
parameters. In other words, a message handler does not care whether "switch x" 
is set because it is set specifically for the current list or because it is set 
for all of the lists within some collection of lists.

Richard
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Exposing not advertised lists via nntp archiver

[Richard Wackerbarth]

On Jul 17, 2012, at 11:07 AM, Barry Warsaw wrote:

> On Jul 15, 2012, at 12:26 AM, Alexander Sulfrian wrote:
> 
>> There are mailinglists with a pubic archive but that not be advertised
>> by the server.
> 'Advertised' lists are kind of a funny middle ground between private and
> public.  They are public lists but don't show up on the overview page.
I assume that you mean "Unadvertised".

> One way to think of this in a mm3 world is that advertisement is purely a
> function of the web ui.

And the equivalent "admin-by-mail" UI.

> For all intents and purposes then, this flag has no impact on public vs. 
> private, so it can be ignored.

But there probably should be a per-list configuration option for gateway-ing a 
list to the news.
There may well be lists for which I am willing to advertise the existence 
without wanting their content to be spread far and wide.

> At least, that's my current thinking, but I'm certainly open to other
> opinions.   I almost wish we could just get rid of the advertised flag.
> 
> -Barry

Richard

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

On Jul 15, 2012, at 12:35 AM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> We should not be required to repeat this in the future. Therefore,
>> we need to have a service level interface for ALL inter-service
>> interactions, even if we do not require the RESTful implementation
>> of those interactions at this time.
> 
> I guess I think of "components" as "interfaces with implementations
> *potentially independent* of other components", and would argue that
> these could (and will) be implemented as separate processes, even as
> remote processes.  These require RESTful implementations AIUI.

I think that "require" is too strong. What is REQUIRED is AN implementation 
that supports separate processes.
Don't mis-understand, I fully expect that the implementation which we develop 
will be a RESTful one. However, I could, just as well, develop one that used, 
for example, SNMP. A specification provides REQUIREMENTS. Since there is no 
fundamental requirement that the inter-service communication be RESTful, that I 
object to describing the service-level interface in terms of a RESTful 
implementation. The service level specification should be more general.

> I would certainly expect that authentication services, the user
> database, the mailflow handlers, owner/site webUI, and user webUI
> would be (conceptually) five separate components, although Postorius
> might provide both owner/site UI and user UI.

Even here, I would start by describing the "site admin UI" and the "user UI" as 
separate services.
>From there, we might describe a "service group" wherein a group of services 
>are implemented in a manner intended to run on a single host. Within this 
>service group, we could allow intra-group communications that bypass the 
>inter-service interface. However, if we do so, we need to be careful that such 
>communications are only alternate implementations for efficiency and do not 
>represent fundamental communications that could not be handled strictly 
>through the inter-service interface. 

> Intracomponent APIs might be defined as zope.interfaces, and even
> "more internal" APIs might be simply Python classes, etc.  But it
> seems to me requiring RESTful interfaces for all intercomponent
> communication is the way to go.

As I indicated above, I consider RESTful interfaces to be only one 
implementation of a conceptual interface.

Richard

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

We need it because we need to maintain that separation of services even for 
service characteristics that do not need to be exposed to an actual REST 
implementation. It is this conceptual separation that keeps the "post routing 
service" separable from the "admin-by-mail service" and the "mailing list 
archive service".

Remember that, as Barry has acknowledged, the IXxx interfaces are an 
implementation-level interface.
If we don't maintain the separation at the "service level", interactions 
between the services which happen to share a common implementation interface 
MIGHT end up bypassing the service level by using capabilities which are 
available in the implementation level, but not in the service level. If they do 
so, it will not be possible to provide an alternate implementation of one of 
those services without also having to provide the alternate for the other 
service.

At present, there is  only an implementation level specification of the 
interface between the "user service" and the other services presently in 
"core". In order to create an alternate implementation of the "user service", 
it will be necessary to unravel these services and assure that they are not 
interacting via any method which is not reflected in the service level.

We should not be required to repeat this in the future. Therefore, we need to 
have a service level interface for ALL inter-service interactions, even if we 
do not require the RESTful implementation of those interactions at this time.


On Jul 14, 2012, at 12:00 AM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> I think that you have missed a level of abstraction.
> 
> Why do we need it?  AFAICS, at this point we have a bunch of services
> that need to be specified somehow.  We *need* a RESTful interface for
> some functions because they make the most sense if accessed remotely,
> and there doesn't seem to be a good reason to go beyond HTTP and
> specify individual transport protocols for these remote services.

Perhaps you still fail to understand what I mean by a service-level interface.

The service-level interface describes the functional interaction between 
objects and controllers.
It deals with conceptual objects and operations. It is not language or protocol 
specific.

ALL transport protocols are below this level.

Consider what is involved when someone wants to change a password:

The storage of the passwords and the later verification of them is handled by 
the "user service".
(That is a statement is a part of the service-level specification.)

There is another service, which is processing the request (hands waived about 
how we get to that point in the data flow, but it is in a service other than 
the user service). How does it accomplish its task?

For discussion, I will call this service the "admin service". After doing 
whatever it needs to do to decide that it is ready,

The (admin) service presents a "user identifier" and the "new password" to the 
"user service" in a "request to change password".
This is another service level specification.

Note that there is no mention of REST interface, or python objects, etc.

It is an implementation detail as to the format in which the "user identifier" 
is presented. It might be a string with the user's Id, a python object of class 
IUser, etc. In fact, the implementation MAY provide multiple signatures for 
this action. The important thing is that the ADMIN service DOES NOT "change the 
password field in the user object".

"change the password field in the user object" might be an internal method 
within the user service, but it is not visible to the admin object.

> Given that, and that REST is a pretty severe restriction, it seems
> likely to me that if we actually need to go beyond REST for
> performance reasons (eg), that can easily enough be done later.  We
> may as well specify using REST now, and have everything target that
> protocol until we need something more powerful or efficient.

Conceptually, I agree. All along, I have been advocating that the service level 
interface be organized in a manner which would allow it to be implemented in a 
RESTful manner.

I suspect that we will find some inefficiencies that would result if every 
operation were actually carried out in that manner and, as a result, in a 
particular implementation, we will group some services and allow them to bypass 
the strict requirement of interacting with each other only through the methods 
exposed in the service-level interface. However, in doing so, we must 
acknowledge that any replacement for one service of that implementation will 
have to replace the entire service group.

Richard

___
Mailman-Developers mailing list
Mailman-Dev

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

I think that you have missed a level of abstraction.

The service, per se, does not REQUIRE a REST interface in order to operate.
It only requires an implementation (in any language) and mutually agreed 
intra-service bindings in a mutually acceptable language.

Because we have chosen a RESTful mechanism as a communications medium for 
services hosted on separate processors, we will need a REST interface 
specification. But, that REST interface is only one implementation of the 
service interface. The REST particulars are not really a part of the service.

Including the locations, etc. are details of a REST IMPLEMENTATION of the 
service interface in the same way that Python classes and methods would be used 
to define a python interface. Or C++ class headers, etc.

Richard

On Jul 13, 2012, at 7:02 PM, Barry Warsaw wrote:

> On Jul 13, 2012, at 05:43 PM, Richard Wackerbarth wrote:
>> I wouldn't even go that far. The service does not need to be DESCRIBED in
>> terms of locations at all.
>> 
>> Certainly, somewhere in the implementation, we would have to provide that
>> CONFIGURATION information, but from the perspective of a consumer of the
>> "user service", my interface is akin to (expressed as meta-language, not
>> code)
>> 
>> services.user_service.change_password(user_identifier, new_password, ... )
>> 
>> It does not matter where, or how, the user_service processes that information
>> except to the extent that I, and the another services, expect it to persist
>> and can later enquire
>> 
>> password_is_valid = services.user_service.verify_password(user_identifier,
>> submitted_password, ... )
> 
> Actually, I think it's essential that we describe the service in terms of
> resources and locations.  The pseudo-code above is an example of a language
> binding, but isn't enough because the implementer of that binding would not
> know where to point the proxy, or how to do the HTTP calls, etc.  In fact, the
> pseudo-code would look significantly different depending on what
> implementation language is used (the above looks Pythonic, but what about
> Ruby, or JavaScript?).
> 
> If we're using REST then the description of the service must be in terms of
> the API that REST exposes, e.g. URLs and JSON (for example).  Then authors of
> the language bindings can expose them to client code in whatever way makes
> sense.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

On Jul 13, 2012, at 2:02 PM, Barry Warsaw wrote:

> On Jul 13, 2012, at 11:56 AM, Richard Wackerbarth wrote:
> 
>> Now, hopefully, we can agree that it is necessary to have a "user
>> service". Further it is reasonable to attempt to have this service distinct
>> from the "post routing service".  The question is then "How will these
>> services interface to each other?"
> 
> I think we're definitely converging on a common language for all the moving
> parts.

That, in itself, is significant. 

>> I agree with the "single interface" aspect of it, particularly if that
>> interface is viewed at the functional level rather than at an implementation
>> level. However, I feel that there should be a complete REST binding for that
>> functional interface.
> 
> WADL is, afaik, the definition language for RESTful web services:

>From your description, I, also, question what we would gain by attempting to 
>use WADL as our formalization language.

> I would be happy enough with human readable  documentation that
> described this user service in terms of resource locations and contents.

I wouldn't even go that far. The service does not need to be DESCRIBED in terms 
of locations at all.

Certainly, somewhere in the implementation, we would have to provide that 
CONFIGURATION information, but from the perspective of a consumer of the "user 
service", my interface is akin to (expressed as meta-language, not code)

services.user_service.change_password(user_identifier, new_password, ... )

It does not matter where, or how, the user_service processes that information 
except to the extent that I, and the another services, expect it to persist and 
can later enquire

password_is_valid = services.user_service.verify_password(user_identifier, 
submitted_password, ... )

> Although it's been years since I read it, Leonard Richardson's definitive
> O'Reilly book RESTful Web Services talks about how this description can even
> (or maybe *should*) be HTML, with links to the actual resources being
> described.

This is a useful technique for publishing documentation where the service is 
being exposed to "outside" consumers.
For example, I may learn that there is a RESTful stock quotation service at 
http:// .  I know nothing more about it.
Since I will be using http to access the service, it is convenient to publish 
usage documentation along with data.

However, in a controlled environment, documenting the interface "python style" 
will, IMHO will be just as useful.

> Or thought about it a different way, mm3's REST API only supports JSON
> representation for resources.  You could implement a parallel representation
> using HTML that included these descriptions.  I bet you could even do this in
> Sphinx in a very human-friendly format, with "base-url" templating so that the
> resource locations are resolvable wherever the user service is deployed.

I'm not opposed to having the documentation published in this, or any other, 
manner.
I would only hope that doing so can be done following the DRY principle.

> Note that this service can have varying levels of compatibility.  E.g. we
> could say that level 1 is required, and define this as the minimal service
> required by the core.  Things like Facebook id would not be in level 1.
> Higher levels would provide additional information that could be used to
> enhance the user experience.  I have no idea whether more than two levels is
> necessary, but I do think there needs to be some discussion of extensibility.

I have some ideas about ways by which we might even make the interface 
"auto-configurable".
-- like passing a query of requirements (or reading a list of capabilities)
For example, through the services manager, "ask" it a webUI service is 
available. If it is, ask the webUI service for the URLs that go into a welcome 
message.  (Or the alternative, always treat things as if there is a webUI. If 
the installer has not configured one, then a default stub would return null 
strings for those requests.

>> This interface can then be implemented by a zope.interface, and/or in any
>> other format appropriate for the implementing code. However, the
>> implementation interface must not provide any inter-service capability that
>> is not reflected in the "interface". Intra-service capabilities are quite
>> useful, particularly when they provide alternate functional signatures which
>> accept local proxies for interacting objects.
>> 
>> Further, as an inter-service design constraint, it should be assumed that the
>> implementation of any service might be "remote" and accessible only by way of
>> the REST interface to it. In addition it

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

Stephen,

>From this posting to which I am replying and other recent ones from Barry, 
>etc. I conclude that it is highly likely that the three of us have somewhat 
>similar conceptual models of an extensible MM system. However, because of the 
>terms that we have chosen in our descriptions, we have failed to communicate. 
>As a result, we have misinterpreted the others' descriptions.

For example, in earlier postings, I used the term "component". Rather than the 
characteristics that Stephen seemed to apply to the term, my intended concept 
is one which, in the text quoted, I would now call a "service" -- a "user 
service" for information related to the persons participating in the lists, a 
"post routing and delivery service" that interfaces with the MTA, an "admin 
handling service" for changing the state of the stored choices, etc. (My exact 
grouping of functionality may not be correct. But that is a separate issue.)

Now, when it comes to interfaces, in that context, I have been referring to 
"service interfaces".
Barry has acknowledged that the (IUser, et al.) zope interfaces are, 
collectively, an implementation-level interface which, presumedly, provides 
capability sufficient to implement the portion of the service-level interfaces 
that are required by the "core" modules provided. They may also provide some 
additional functionality that someone anticipated to be of use by other 
services which might wish to interact with these interfaced objects.

Similarly, I now believe that Stephen's use of "core database" was more a 
reference to the union of all of these service-level interfaces rather than 
that of the interpretation which I had placed on the term, namely a "persistent 
store running in conjunction with the post routing service"

Now, hopefully, we can agree that it is necessary to have a "user service". 
Further it is reasonable to attempt to have this service distinct from the 
"post routing service".
The question is then "How will these services interface to each other?"

Stephen says:
> ... having a single interface (with perhaps a REST "binding" for IPC and a 
> direct
> zope.interfaces binding for within-process use)

I agree with the "single interface" aspect of it, particularly if that 
interface is viewed at the functional level rather than at an implementation 
level. However, I feel that there should be a complete REST binding for that 
functional interface. This interface can then be implemented by a 
zope.interface, and/or in any other format appropriate for the implementing 
code. However, the implementation interface must not provide any inter-service 
capability that is not reflected in the "interface". Intra-service capabilities 
are quite useful, particularly when they provide alternate functional 
signatures which accept local proxies for interacting objects.

Further, as an inter-service design constraint, it should be assumed that the 
implementation of any service might be "remote" and accessible only by way of 
the REST interface to it. In addition it should be assumed that the 
implementation of that service will be in an arbitrary programming language 
other than python. Designs which violate either of these assumptions should not 
be accepted because they reduce the ductility of the interface.

The implementation interfaces provide only a proxy for the conceptual objects 
defined in the service interface and any action on those proxies needs to be 
conveyed to the conceptual object by means of an access specified in the system 
interface.

Richard


On Jul 12, 2012, at 10:03 PM, Stephen J. Turnbull wrote:

> Barry Warsaw writes:
> 
>> The question is whether we want to support running the core without
>> having this user service available, i.e. in standalone mode.  Are
>> we going to require that this service be running in order to run
>> the core?  I think we shouldn't be so strict.
> 
> But *some* user service needs to be available.  This is to my mind a
> core component of Mailman in any case.  I don't see why having a
> single interface (with perhaps a REST "binding" for IPC and a direct
> zope.interfaces binding for within-process use) and a default
> implementation of that service as a core component (but separate from
> the post routing and delivery and admin routing and handling services)
> would be very costly in implementation and maintenance, but it ensures
> the flexibility to deal with unknown future requirements everybody
> says is important.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

On Jul 11, 2012, at 9:53 PM, Barry Warsaw wrote:

> On Jul 11, 2012, at 09:27 AM, Richard Wackerbarth wrote:
> 
>> First, we should define all of the data storage in terms of the REST access
>> points to the data. (And not, as presently done, the other way around) Next,
>> we should access all of the REST interface URLs indirectly so that
>> functionality can be moved around simply by changing a single reference
>> definition.  This is the kind of scheme that django uses with its {% url %}
>> tag. (like DNS vs IP addresses) Finally, we should "black box encapsulate"
>> the access to the data, requiring that EVERY module utilize this common
>> interface, and only this interface, to the data.
> 
> If there were a separate user database that exposed all sorts of data via
> REST, including stuff the core doesn't care about, then all the things I
> described before about re-implementing various Zope interfaces in the core
> holds true.  They would just do REST calls instead of database queries.

Agreed.

> Both implementations in fact can live side-by-side, and choosing one or the
> other is something you do when you install and configure the system.

I'm not sure that I agree with attempting to maintain two implementations 
"side-by-side"

"separate, but equal" comes to mind.   And we all know how that worked.

My preference remains to use the REST interface to define the object contract.
By that, I mean that every action performed on the object is isomorphic to a 
REST interaction.

To do otherwise creates an inequality between those accessing the object.

> -Barry

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

... taken out of sequence ...
>> That is because you have not followed the principles and allow
>> "someone else" to provide that service.
> 
> True.  (I wish you'd stop using "you" in this kind of statement; it
> isn't true, I didn't code any of this.  And it doesn't matter who

I apologize for my terminology. Rather than using the second person, I should 
use the third. However,
no where do I mean "you" to reflect on you personally. I tend to use personal 
pronouns as a short form representing "the argument/proposal/design that, in 
the context of the message, is being described by a particular person", as 
distinguished from one which another person has described/advocated. Similarly, 
if I were to use "Barry" in that context, I would be referring to an idea that 
he has described. I do not know, necessarily, if any methodology is the 
preferred approach of the individual describing it.

There seems to be two fundamental design strategies being discussed.
One of them has a monolithic data store and the other has a distributed store.
Barry has expressed some reservations about overloading a monolithic data store 
with data extraneous to the fundamental mission of message handling.

I have expressed concern in requiring any implementation to maintain related 
data in a split format.
I recognize that there will be cases where this is necessary (for example the 
Launchpad case as described by Barry in another message). But, as he notes, 
such implementations tend to be "brittle". Especially where there are multiple 
components which can alter the data.  But, unless it is a constraint external 
to MM, I do not believe that such a restriction should be introduced.

There is also an issue of what the term "core" means. Perhaps you have been 
referring to a distribution package. I have been referring to one component of 
such a package, in particular that component which interacts with the MTAs and 
redistributes messages. I consider the processing of administrative messages to 
be a separate component. And I consider the storage of configuration 
information to be yet another component. In my view, each component extends 
only as far as its parts interact with the same private data representation.

On Jul 12, 2012, at 2:05 AM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
>> I don't pretend to know just what our users will want to add. But
>> they should be allowed to write an SQL-type description of their
>> needs and they shouldn't "muck" with the inner workings of the
>> message handling schema to do so.
> 
> So by "SQL-type" do you mean they *must* have access to the RDBMS so
> they can actually write SQL, or just that the provided interface needs
> to allow queries with logical operators?  The "-type" suggests you
> mean the latter.

I do mean the latter. But, if the real underlying database is a RDBMS, then, 
within the "black box", these queries probably should be implemented by 
translating them to real SQL queries and passing those to the RDBMS.
There has been a lot of work, by many far more qualified that we, to handle 
such details within the RDBMS. We should not attempt to reinvent their wheel.

> But you've also suggested the former.

I have suggested it as an alternative implementation. I do so only because that 
strategy exposes a powerful resource and avoids the burden of adding a new 
mechanism in order to meet the requirement for customized extensions and access 
that need to interact efficiently with the data that MM needs to have 
maintained.

>  I don't like the idea of direct
> access to the underlying database, because there isn't necessarily
> going to be just one, and it may be that Mailman needs certain kinds
> of access to component DBs (eg, updating email addresses) but the
> organization would like to have access controls on them based on
> another component database (authorized admins, say).  Also, we're not
> in a position to require that all databases be kept in, say,
> Postgresql.  They may not even be RDBMSes (LDAP member databases,
> sendmail alias files).  So we need a layer of abstraction.

I agree that we need the abstraction.

>> I don't see user passwords providing much direct use in the mail
>> distribution system.
> 
> I don't understand what you're thinking.

First, we seem to have a different conceptual model of MM.
I view that which is being called "core", not as a single entity, but a 
collection of components, most of which are critical to the operation of the 
system.
Among those components, I distinguish message routing and distribution, 
configuration storage, and processing of administrative messages.

The first is what I have been calling the message han

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

In many respects I think that we are in agreement.

If I understand you, we both envision a distributed database whereby any of the 
components might actually provide the data storage for some specific class of 
information. For example, without specifying where in the system it will 
reside, there is a "UserManager" that maintains information about the users. It 
would also be responsible for registering ALL user instances and providing 
lists of users that meet certain constraints. In addition, it provides an 
access mechanism for properties associated with particular users.

However, I think that we differ in terms of the public interface specifications.

The specification that you suggest produces a particular python object.

The specification that I suggest contains only those characteristics which are 
exposed on the REST interface.
It does not specify the exact format in which those characteristics are 
presented, but only what characteristics are available and what operations can 
be performed. In this form, no component external to the UserManager is 
permitted to rely on any aspect of the representation which falls outside of 
the available public characteristics.

The place where I am unclear of your intentions concerns this python object. In 
theory, it may have characteristics that are not exposed to the REST interface. 
Do you permit your functional modules, (the message handler or the 
administration interface, for example) to rely on any characteristics that are 
not properly exposed by the REST interface. If so, why?

On Jul 12, 2012, at 10:07 AM, Barry Warsaw wrote:
>> I think that this is the wrong approach to the extent that "core", and here,
>> by "core" I think you mean the "admin-by-mail" component, does anything other
>> than call the same REST interface that the web UI would use.
> 
> It could, though internally, that would be hidden behind the implementation of
> IUserManager, IUser, and associated objects. We're saying the same thing but
> in a different way.  The advantage of hiding this behind the zope.interfaces
> is that we can have multiple alternative implementations of those interfaces,
> so that whether it's REST or a SQL call doesn't matter to most of the core.

>>> So for example, an IMember associates an
>>> IAddress with an IMailingList.  The standard implementation of that doesn't
>>> use a foreign key between the `member` table and the `mailinglist` table.
>>> Instead it uses the fqdn_listname, i.e. a string.
>> 
>> I don't agree. Your string which contains the fqdn_listname IS a foreign key
>> to the mailinglist table. It may not be the primary key in some
>> installations, but it is one-to-one with that key and could be used directly
>> as the primary key.
> 
> The point is that it's not a foreign key constraint in the members table.

OK, I think we are in agreement WRT this concept. You seem to have taken 
"foreign key" to imply a specific implementation of the concept to which I was 
referring, namely some key which designates a unique instance in the referenced 
table.

> Doing that would, I think, prevent you from putting the mailinglist table in
> one database and the member table in another.  It makes the associated queries
> less efficient, but provides for a useful measure of flexibility.

Were this not Python, but C++, I would suggest that we consider offering 
multiple signatures for the exposed functionality. For example, it the function 
were to deliver a list of MLs to which an Address is subscribed, the address 
might be provided as a string (the email address in canonical form), the pk of 
the entry in the underlying Address database, or as an object of the Address 
class.

Although the same could be done in python through introspection, or similar 
techniques, I don't know to what extent doing so would introduce inefficiencies.

> P.S. FWIW, I think this separate "user database" component with REST calls in
> the IUserManager (et al) implementation would not actually be difficult to
> mock up.  I don't have the time to do the coding, but would be happy to
> discuss details if someone wanted to take a crack at it.

I definitely will take a crack at it since I suspect that doing so would allow 
Postorius to have all of its user information handled in one place and still 
provide the "admin by mail" to work with its restricted expectations.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

On Jul 11, 2012, at 9:05 PM, Barry Warsaw wrote:

> Thanks for starting this discussion.  Since the thread's already long, I'm
> just going to answer randomly with my own thoughts.

And thanks for your reply. I just spotted something in it that makes me feel 
that rather than fundamental disagreement, we may simply be saying things 
differently.  I'll dig through all of the rest of your remarks in detail at an 
appropriate interval.

> One thing I have a real problem with is defining the database query layer as 
> the interface between components.

Note that I expressed the preference that the interface be defined in terms of 
the REST access.

As I say in another post, it is not the exact expression of the interface that 
is important, but that all of the descriptions are isomorphic and that no 
component accesses shared data by "private" methods.

> There *should* be enough hooks in the system already for a system

> administrator to say "I want to use Postorius, so I must enable the Postorius
> IUserManager implementation".

And, by saying this, you  imply that the storage of passwords is no longer the 
responsibility of "core".

You have delegated it to IUserManager. And the default Postorius compatible 
IUserManager could store those passwords where ever it wishes. In particular, 
it can store them in the Postorius User database, along with all of the other 
User profile information that the site wants to keep.
> because everything talks to that object through the interface, and as long as 
> that keeps its contract, the rest of the system should, again Just Work.

> I have no idea whether the above will be easy or not, since nobody's tried
> it.  But the system design should allow you to do it this way, and I would be
> very open to the right hooks, fixes, and extensions to make this possible.
> I hope you can see how this approach lets someone run Mailman in many
> different configurations, from a core-only system, to Postorius, to a system
> where all the user database is in ZODB or already locked up in a proprietary
> closed database.
> 
> There is another approach of course, which may end up being simpler, if more
> brittle.  You could just try to keep the two databases in sync.  It doesn't
> matter too much which is the master, you just have to decide.

Yes, but from my experience, only with great care. As you note that arrangement 
is brittle. I would prefer to avoid it.

> Once the core acts on that change, it will trigger a PasswordChangeEvent 
> which has a reference to
> the user effecting that change.  If Postorius was the master database for
> passwords, we'd have to add a little event subscriber which, when it got a
> PasswordChangeEvent, then talked to Postorius to make that change.  Or maybe
> it updated the shared user data component, or made the appropriate SQL UPDATE
> call.  The key thing again, is that the core just fires the
> PasswordChangeEvent, and other things react to it.
> 
> Alternatively, let's say a user changes their password through the web ui.  I
> think this case is already covered, because the way to keep that in sync with
> the core is to make the appropriate REST call, probably PATCHing the user's
> password.

I think that this is the wrong approach to the extent that "core", and here, by 
"core" I think you mean the "admin-by-mail" component, does anything other than 
call the same REST interface that the web UI would use.

The implementation of that interface item could reside anywhere in the system 
and it would manipulate the database through the IUserManager.

- - - -
> So for example, an IMember associates an
> IAddress with an IMailingList.  The standard implementation of that doesn't
> use a foreign key between the `member` table and the `mailinglist` table.
> Instead it uses the fqdn_listname, i.e. a string.

I don't agree. Your string which contains the fqdn_listname IS a foreign key to 
the mailinglist table. It may not be the primary key in some installations, but 
it is one-to-one with that key and could be used directly as the primary key.
- - - -
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

On Jul 11, 2012, at 3:29 PM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> No! Although you are making available (some/most/all) of the data
>> values, you are not making available the ability to make arbitrary
>> SQL-type queries to view the data.
> 
> AFAIK the plan is to do that via the REST interface.  I don't see why
> they need to be "arbitrary SQL-type" queries; you need to be a bit
> more explicit about that.

As an example, suppose that I want to have an "intelligent" ToDo indicator.
As a minimum, I need to be able to get from the data store a list of MLs that 
have pending requests AND for which I am authorized to do that work.  
Typically, this would be some kind of join.
Or the "social media" guys might want to add some "respected author" value and 
incorporate that into the way that messages get displayed. That data doesn't 
even exist in the "stock" distribution.
I don't pretend to know just what our users will want to add. But they should 
be allowed to write an SQL-type description of their needs and they shouldn't 
"muck" with the inner workings of the message handling schema to do so.

> The point is that the message distribution agent is mission-critical;
> if it goes down you are well-and-truly screwed.  If the web UI goes
> down, it might not even be noticed for weeks.

I don't buy that.  If you advertise a subscribe URL, or any other function,
that is just as much a "mission critical" component as any other.

I don't see user passwords providing much direct use in the mail distribution 
system.
They might be critical to a list that requires moderation. But, even there, I 
suspect that the moderators are likely to utilize the web interface.

>> I think we MUST assume that there will be a web interface.
> 
> Of course there will be a web interface.  As you point out, we
> couldn't even give away the product without it.  But there might be
> half a dozen different ones, too.
> 
>> As far as the complexity of access is concerned, the mail handler
>> probably has the lowest requirements. The present architecture
>> would have to be extended significantly to provide for appropriate
>> handling of ALL of the data. That includes a much richer query
>> capability.
> 
> So what?  This extension needs to be done *somewhere*; you aren't
> going to be able to avoid it by throwing it out of the core.

No, but I will "compartmentalize" it.

>  What you are going to be able to do by throwing it out of the core is ensure
> that each non-core module will do it differently and incompatibly.

No, I am suggesting that either you implement the functionality by specifying 
that some particular structure be set in a standard database (and provide a 
reference implementation of doing so) or that you specify REST interfaces that 
implement the appropriate functions and REQUIRE that all components manipulate 
that data ONLY through those interfaces.

The REST interface is not a single entity, but a collection of components that 
inter-operate. Each of them is "mission critical".

Further, "each non-core module will do it differently and incompatibly" is a 
red herring. There MUST be a SPECIFICATION of the interface and EVERY 
implementation MUST meet those REQUIREMENTS. What ever else it does will not 
affect any other part of the system.

>  In fact, as you point out, they already are different and incompatible.

That is because you have not followed the principles and allow "someone else" 
to provide that service.

> I don't see any reason for that to change unless the DB API is
> centralized somewhere.
> 
> I see no reason for that somewhere to be anywhere but the core.  The
> core is the only component that we *know* *has* to be there, and there
> will be only one implementation of it.  The various UIs have
> substitutes, and one reason for splitting them out was to make it
> possible to have multiple implementations (and you've been at pains to
> point that out).

>> Presently, the message handling is integrally tied to the database
>> implementation. Customization extensions will intrude into parts of
>> the system which they should not affect.
> 
> Why?  Parts of the system that don't need them just ignore them.
> Where's the problem?

Spaghetti. In any system of complexity, there will be parts that could care 
less about the details of most other parts.
design modularity practices separate those parts and provide limited access 
between them.

>> I view your argument as the message handler claiming "I'm special!
> 
> It is.  First, it is mission-critical; nothing else is.

And the underlying RDBMS, the MTA, etc. are not?

>

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

On Jul 11, 2012, at 12:50 PM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> Pretty soon, you will find that what you need approaches something
>> that already exists -- a relational database.  Rather than
>> "reinventing the wheel", we should just use an already existing
>> database system and make all of the data directly accessible.
> 
> We're already doing that, with ORMs overlying the RDBMS.

No! Although you are making available (some/most/all) of the data values, you 
are not making available the ability to make arbitrary SQL-type queries to view 
the data.

>> Since only a minimum of information is essential to the core job,
>> it may well be more appropriate for it to get that information from
>> another source as needed.
> 
> True, but we've already agreed that the user information should be
> kept in one place, based on your experience.
> 
>> Applying your previous argument, I could equally say "since the web
>> user needs to be authenticated, we may as well keep all such
>> information in the webUI's database"
> 
> It's not the same argument.  A mailing list needs a message
> distribution agent; it doesn't *need* a webUI.

In this day and age, try selling that one! Only those of us, and that 
especially includes me, who were around "way back when", before http even 
existed, know any other way. :)

Additionally, look at what other MM developers are doing. For example, 
Hyperkitty is not oriented to retrieving archived messages by email. I think we 
MUST assume that there will be a web interface. If someone wants to have a 
mailing list without one, it should be easy enough to "stub off" the limited 
amount of user information that is needed. But I think that this use case will 
be the exception rather than the rule.

> There may be implementation reasons why it's better to handle database
> requirements in the webUI or a new daemon, but nobody's given any yet.


As far as the complexity of access is concerned, the mail handler probably has 
the lowest requirements. The present architecture would have to be extended 
significantly to provide for appropriate handling of ALL of the data. That 
includes a much richer query capability.

Presently, the message handling is integrally tied to the database 
implementation. Customization extensions will intrude into parts of the system 
which they should not affect.

As far as I am concerned, those are more than adequate reasons.

I view your argument as the message handler claiming "I'm special! Everyone 
else has do do things my way. I get special privileges."  -- IMHO, the tail is 
wagging the dog.

Let's split shared data storage from the message handler, and from any 
"admin-by-mail" component, treating each of them as separate logical 
components. Provide each of them EXACTLY the same accesses as those provided to 
the WebUI, Message Archiver, etc.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

The problem in splitting data is that links between the various related entries 
need to be maintained.
This means having the ability to go from one entry to the related ones, and 
back again.
When the data is stored in multiple tables, foreign keys provide the link. When 
both tables reside in the same database, joins can be performed, etc. However, 
when the tables are in separate databases, at a minimum, each database needs to 
"know about" (store the inverse key) the other entries. They also need to be 
able to assure that the corresponding entries in the foreign tables get 
created, and likely require that they be unique. Because of thread locking 
considerations, this may not be so easy to accomplish.

On Jul 11, 2012, at 10:07 AM, Florian Fuchs wrote:

> Hi there,
> 
> Am 11.07.12 15:34, schrieb Richard Wackerbarth:
>> On Jul 11, 2012, at 8:14 AM, Stephen J. Turnbull wrote:
>>> Richard Wackerbarth writes:
>>> 
>>>> What I am advocating is that the "core" message handler NOT be the
>>>> keeper of ONLY PART of it.
>>> 
>>> What I'm advocating (mildly, because somebody else is going to have to
>>> do the work) is that the core be the keeper of ALL of it.  The core is
>>> not just a "message handler".  It is also a database, containing both
>>> list information and subscriber information.  
> 
> If we're only talking authentication data, I agree.
> 
> But I also agree with Terri that there might be a good amount of user
> data used by Postorius, Hyperkitty or any other web ui/client that just
> doesn't have anything to do with mailman's core tasks. And I don't see
> why something like "preferred ui theme" or profile-related stuff like
> "irc nick" should be stored in the core db.
> 
> Isn't it very common that applications combine information from
> different sources (databases, webservices,...) in one place (with or
> without caching them locally)? I don't see anything unusual in the
> concept of having some mailman-related user data managed by the mailman
> core and other kinds of data handled by the
> database/file-structure/key-value-store/web-service(s) that a web
> application is using.
> 
> If Postorius and HyperKitty decide to share some information in one
> place, because the projects are so closely related, that's of course a
> fine idea. But I wouldn't try to cram everything into the core db just
> for the sake of having it all in one place.
> 
> Florian
> 
> 
>> 
>> OK, so we agree that ALL of the information SHOULD be stored in one place.
>> That means that this database will need a lot more information, such as 
>> access control specifications, etc.
>> Further, it needs to be extensible so that various users can add whatever 
>> customizations and extensions they need.
>> 
>> And each of those functions will need supporting views, etc.
>> 
>> Pretty soon, you will find that what you need approaches something that 
>> already exists -- a relational database.
>> Rather than "reinventing the wheel", we should just use an already existing 
>> database system and make all of the data directly accessible.
>> 
>>> Since a minimum of subscriber information is absolutely essential to the 
>>> core job, all of
>>> it may as well be in there.
>> 
>> This does not follow logically.  Since only a minimum of information is 
>> essential to the core job, it may well be more appropriate for it to get 
>> that information from another source as needed.
>> 
>>> In some configurations we will want the subscribers to be authenticated, so 
>>> we may as well keep all such
>>> information in the core's database.
>>> 
>>> Steve
>> 
>> Applying your previous argument, I could equally say "since the web user 
>> needs to be authenticated, we may as well keep all such information in the 
>> webUI's database"
>> 
>> Richard
>> ___
>> Mailman-Developers mailing list
>> Mailman-Developers@python.org
>> http://mail.python.org/mailman/listinfo/mailman-developers
>> Mailman FAQ: http://wiki.list.org/x/AgA3
>> Searchable Archives: 
>> http://www.mail-archive.com/mailman-developers%40python.org/
>> Unsubscribe: 
>> http://mail.python.org/mailman/options/mailman-developers/f%40state-of-mind.de
>> 
>> Security Policy: http://wiki.list.org/x/QIA9
>> 
> 
> ___
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

On Jul 11, 2012, at 1:55 AM, Terri Oda wrote:
> *  We'd also like to do openid, which means we need to somehow associate an 
> openid token with an email address.
> 
> So right now, postorius needs email address, username (for direct 
> authentication), and potentially a list of openid or other tokens.  That's a 
> small enough list that we may be able to justify making mailman core aware of 
> a small token list (or a single openid token?), or we can let postorius 
> handle that and have core only understand "I am the owner of this email 
> address -- let me see the associated settings of me."  I think my preference 
> would be to have mailman understand more than email/password authentication, 
> because I think it'll make things easier and not have us duplicating data in 
> hyperkitty etc, though.

> The messy part, IMO, is what to do with the non-authentication user data. I'm 
> guessing we'll probably want some sort of theme preference data (possibly 
> shared between postorius/hyperkitty/others?).  Not sure what else.  That 
> stuff... really doesn't have much place in core, but probably will need to be 
> shared between several web components... do we have a second rest server for 
> user data?

If we are going to use REST interfaces to tie components together, then, in the 
design, we should do a few things differently.

First, we should define all of the data storage in terms of the REST access 
points to the data. (And not, as presently done, the other way around)
Next, we should access all of the REST interface URLs indirectly so that 
functionality can be moved around simply by changing a single reference 
definition.  This is the kind of scheme that django uses with its {% url %} 
tag. (like DNS vs IP addresses)
Finally, we should "black box encapsulate" the access to the data, requiring 
that EVERY module utilize this common interface, and only this interface, to 
the data.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

On Jul 11, 2012, at 8:14 AM, Stephen J. Turnbull wrote:
> Richard Wackerbarth writes:
> 
>> What I am advocating is that the "core" message handler NOT be the
>> keeper of ONLY PART of it.
> 
> What I'm advocating (mildly, because somebody else is going to have to
> do the work) is that the core be the keeper of ALL of it.  The core is
> not just a "message handler".  It is also a database, containing both
> list information and subscriber information.  

OK, so we agree that ALL of the information SHOULD be stored in one place.
That means that this database will need a lot more information, such as access 
control specifications, etc.
Further, it needs to be extensible so that various users can add whatever 
customizations and extensions they need.

And each of those functions will need supporting views, etc.

Pretty soon, you will find that what you need approaches something that already 
exists -- a relational database.
Rather than "reinventing the wheel", we should just use an already existing 
database system and make all of the data directly accessible.

> Since a minimum of subscriber information is absolutely essential to the core 
> job, all of
> it may as well be in there.

This does not follow logically.  Since only a minimum of information is 
essential to the core job, it may well be more appropriate for it to get that 
information from another source as needed.

> In some configurations we will want the subscribers to be authenticated, so 
> we may as well keep all such
> information in the core's database.
> 
> Steve

Applying your previous argument, I could equally say "since the web user needs 
to be authenticated, we may as well keep all such information in the webUI's 
database"

Richard
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

Stephen,

I'm not advocating that Postorious be THE keeper of the user information. But 
it would be a good candidate for the job.

What I am advocating is that the "core" message handler NOT be the keeper of 
ONLY PART of it.

I am perfectly happy to have the user info handled by an independent 
stand-alone module which is willing to take responsibility for ALL of the user 
profile info. It should provide a REST interface that allows other modules the 
ability perform authentications, manipulate the profile, etc.

Another acceptable methodology would be to store all of the data in a real 
relational database and allow each of the modules direct access to the database 
engine.

Richard

On Jul 11, 2012, at 12:12 AM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> Since by far the most complicated, and most used, logins will be
>> made from the web interface, it is much more logical to allow
>> Postorius to be responsible for all of the user profile information
>> and have the core, on those rare occasions where it requires it,
>> obtain password confirmation from that source.
> 
> From the point of view of Postorius implementers, no question about
> it.
> 
> But isn't that going to take us a long way down the road where we
> anoint Postorius the one-and-only admin interface?  If that really
> needs to be, OK, but I don't much like it.  Among other things, it
> will make the design and detailed UI of Postorius a focus of
> discussion for everybody concerned with Mailman 3.  And it makes the
> option to "build one to throw away" much more difficult -- the design
> decisions already made, and will be made in the near future, will
> probably live as long as Pipermail has (and Pipermail will continue
> for several more years, at least!)
> 
> If that doesn't scare you
> 

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

Yes, it is a bug in Postorius. However, that does not negate the fact that the 
present design, by forcing a split database, makes it difficult to accomplish 
the desired behavior.

As far as I am concerned, if Postorius is corrected to handle this situation 
robustly, it will be in spite of, and not with the help of, the design being 
forced upon it.

Since by far the most complicated, and most used, logins will be made from the 
web interface, it is much more logical to allow Postorius to be responsible for 
all of the user profile information and have the core, on those rare occasions 
where it requires it, obtain password confirmation from that source.

Richard

On Jul 10, 2012, at 9:14 PM, Stephen J. Turnbull wrote:

> Richard Wackerbarth writes:
> 
>> I am encountering a problem with login on Postorius. There is no
>> mechanism to keep the MM user database synchronized to the one
>> which django creates.
> 
> Since Postorius is the facility by which admins will expect to access
> the user database, I have to consider that a bug in Postorius.
> 

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

[Mailman-Developers] Login / User Identification Issues in MM3

[Richard Wackerbarth]

I am encountering a problem with login on Postorius. There is no mechanism to 
keep the MM user database synchronized to the one which django creates. If you 
use BrowserID to log in, or if you are otherwise in the django user database, 
this is currently causing a access error for any user that was not previously 
defined in the MM database when attempting to access the MM interface.

Further, in implementing extensions to the login function, having the password 
(but not the other user profile information, including alternate credential 
specifications) on a separate system greatly complicates the handling of login.

It would greatly simplify things if all of the user information, including 
profile, and whatever information the "social media" folks want to keep, were 
stored in one place.

If we are not going to have a single database, to which all components of the 
system have equal access, then I suggest that we treat the user information as 
a separate realm from both the UI and the "core" and require both of them to 
access that information through the same REST interface.






___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [Bug 1020683] Feature Request: Make regular_*_lists and *_these_nonmembers recursive (and aware of each other).

[Richard Wackerbarth]

On Jul 5, 2012, at 2:48 PM, Robert Arlt Jr. wrote:
> I can as well.  In my view of the issue I believe that allowing everyone
> on listB to submit is the better option as I can easily make a list
> composed of those allowed to send unmoderated to listB, call it listB2
> and add listB2 to listB then use listB2 as the list allowed to send to
> listA (all of this assuming recursion is implemented).

But that would be confusing to the members of listB. They would have to realize 
that they are not really a member of listB, but that they are actually a member 
of listB2.

So, if you are going to do that, and perhaps for any inclusion that is 
transparent on message delivery, an attempt to change delivery preferences on 
listA should take the user to the listB2 preferences.

However, if the delivery of listA is done by publishing a copy of the message 
on listB, then, for the purpose of preferences, the listB user should not be 
considered a member of listA.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] [Bug 1020683] Feature Request: Make regular_*_lists and *_these_nonmembers recursive (and aware of each other).

[Richard Wackerbarth]

Robert,

Although I recognize your goal, it isn't as easy as simply providing transitive 
membership.

First, I presume that you are willing to restrict yourself to the case where 
lists listA, listB, and listC are served by the same instance of MM.
On the distribution side, that restriction certainly is not necessary for list 
inclusion, but, in general, there is no mechanism for listA to learn the 
members of listC unless they are served by a common server instance.

Even so, the issue is whether, or not, everyone who receives listB should be 
allowed to submit to listA (without moderation). Or perhaps you would only want 
those who can make unmoderated submissions to listB to have that transitive 
permission.

I can visualize both use cases.

Richard

On Jul 5, 2012, at 12:53 PM, Robert Arlt Jr. wrote:

> I think making it recursive would be sufficient.
> 
> However, it isn't really that I want *_these_nonmembers to be recursive
> to *_these_nonmembers as I may want different sets of lists to be able
> to send to a particular list.  I guess it might be better if I just
> explained what I really want, which is the ability to add @listC to the
> members of listB such that listA, which has accept_these_nonmembers set
> to @listB, can be sent to unmoderated by members of listC.  In
> otherwords making the @listname format usable as a list member such that
> *_these_nonmembers and sibling lists can transverse them.
> 
> Neither of the solutions you have talked about are exactly that, but
> could be used instead to obtain the same goal.  Basically what I am
> trying to do is minimize the number of lists that would have to be
> changed if a new lists is created that should have rights to send to a
> number of lists.
> 
> Perhaps I should have split this into two feature requests, the
> recursion request is by far more of a useful feature.  The other feature
> would add on only a minimal amount of capability.
> 
> -- 
> You received this bug notification because you are a member of Mailman
> Coders, which is subscribed to GNU Mailman.
> https://bugs.launchpad.net/bugs/1020683
> 
> Title:
>  Feature Request: Make regular_*_lists and *_these_nonmembers recursive
>  (and aware of each other).
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mailman/+bug/1020683/+subscriptions
> ___
> Mailman-coders mailing list
> mailman-cod...@python.org
> http://mail.python.org/mailman/listinfo/mailman-coders

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] MM3 - Using fqdn in the exposed URLs

[Richard Wackerbarth]

Perhaps you should consider a different strategy that does not couple so 
tightly the SQL schema with the parameters.

Rather that having an object which tries to keep everything directly on the 
object, place many of those values in a dictionary and do (key, value) lookups 
on the dictionary rather expecting the key to be a property of the object 
itself.

That way, additional values can be associated with the object without changing 
the underlying database schema.

Richard


On Jun 12, 2012, at 9:58 AM, Barry Warsaw wrote:

> On Jun 12, 2012, at 08:01 AM, Richard Wackerbarth wrote:
> 
>> Core will need to be provided a dictionary of items related to the
>> configuration of the list infrastructure.  The URL for subscriber account
>> maintenance is one of those items.  However, the contents of that field, or
>> any of the others, and how they are derived, is outside the scope of "core".
>> To core, these are just configuration constants.
> 
> It does, and it's not difficult to add new variables, except for the nightmare
> (currently ongoing) of migrating the SQLite schema.

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] MM3 - Using fqdn in the exposed URLs

[Richard Wackerbarth]

On Jun 12, 2012, at 5:16 AM, Florian Fuchs wrote:
> 1) We could change this part of the URLs to something like:
> . This way we can compose the full
> fqdn_listname from the URL but it's not as obvious as the list's email
> address (it's also still readable).
> 
> 2) Adding to Richard's slug idea: We could provide a "slug"-field in the
> list settings (and create list) form. The default slug is the format
> described in 1) - but an admin can change it to any custom (and shorter)
> slug they like (as long as it's unique).

+1

> I suggest that we save the slug/fqdn_listname mapping in a local db
> table (it's only a ui specific setting, so the core doesn't need to know
> about it).

Core will need to be provided a dictionary of items related to the 
configuration of the list infrastructure.
The URL for subscriber account maintenance is one of those items.
However, the contents of that field, or any of the others, and how they are 
derived, is outside the scope of "core".
To core, these are just configuration constants.

> Cheers
> Florian

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Re: [Mailman-Developers] MM3 - Using fqdn in the exposed URLs

[Richard Wackerbarth]

Actually, the Django methodology would allow the website designer to choose any 
URL that she wishes.
So, Postorius should be able to set a configuration parameter to any value that 
the designer chooses and "core" would just be echoing it.

Richard


On Jun 11, 2012, at 11:28 AM, Barry Warsaw wrote:

> On Jun 11, 2012, at 05:43 AM, Richard Wackerbarth wrote:
> 
>> I think that we should rethink this decision and follow a "slug" approach to
>> the identification of the mailing lists in URLs. Those who choose to do so
>> can use the fqdn as their slug. But others would be able to readily change
>> the mapping without having to rewrite significant parts of the interface
>> code.
> 
> I agree that the shorter-url argument is more compelling than the
> security-by-obscurity argument.
> 
> If the mapping need only happen in one direction, then something as simple as
> hashing the mlist fqdn and taking a substring would probably be good enough.
> 
> -Barry

___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: 
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9