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

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_list@examp... would return the URI representing the list
https://server.example.com/mailman/attribute/posting_address/test_list@examp... might return test_list-join@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 <raj.abhilash1@gmail.com> 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.)
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?
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
?

Richard Wackerbarth writes:
"ABCDEFG" is what? The list?
I think the short prefix /mailman/ should be reserved for traditional and anonymous requests. /mailman/rest_api/ or some such for the REST API.
This is what you mean by self-documenting? Presumably it returns not only the attribute names, but their ranges (types) and docstrings?
https://server.example.com/mailman/attribute/posting_address/test_list@examp... would return the URI representing the list
Why have you changed the order of components here?
https://server.example.com/mailman/attribute/posting_address/test_list@examp... might return test_list-join@example.com
Huh? This isn't a syntax error?

On Apr 27, 2013, at 2:42 AM, "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> wrote:
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 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.
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.
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_list@examp... might return test_list-join@example.com
Huh? This isn't a syntax error?
Probably is syntactically incorrect. The email address would need to be URL escaped.

Richard Wackerbarth writes:
"ABCDEFG" is what? The list?
Yes. But note that it is some pk provided by the list store.
"pk" ?
So "attribute/posting_address/test_list@example.com" is a query that means "give me a way to indicate this list"?
These URIs are pretty ugly. Surely we can do better?

On Apr 27, 2013, at 8:19 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
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.
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.

Richard Wackerbarth writes:
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.
These URIs are pretty ugly. Surely we can do better?
Perhaps we can. But we need to conform to the HAL framework style.
Well, I haven't studied it carefully, but the examples on Mike Kelly's pages are pretty enough.
From the consumer's point of view, yes, the links are discovered. But the producer constructs them.

On Apr 27, 2013, at 10:36 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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.

Richard Wackerbarth writes:
Being able to "write URIs by hand" is a violation of the HAL design because it locks the interface into a particular implementation.
Sorry, that's an un-Pythonic way to think. If HAL really requires URIs that only a machine can deal with, let's junk it. "If the implementation is hard to explain, it's a bad idea."
But I really don't think HAL requires that.

On Sat, Apr 27, 2013 at 6:34 AM, Richard Wackerbarth <rkw@dataplex.net>wrote:
The rules of good endpoint is very simple. * For first-class resources collections endpoint: <domain>/<api_prefix>/<version>/<collection name>/ e.g. http://list.mailman.org/api/v1/users document endpoint: <domain>/<api_prefix>/<version>/<collection name>/<doc_id>/ e.g. http://list.mailman.org/api/v1/users/ID1234567/ * Don't use path as tools of deep query, use query string for query e.g. http://list.mailman.org/api/v1/users/?subscriptions="mailing_list_abc" * Use hyperlinks for references between first-class resources in documents: e.g. curl localhost:5000/api/v1/users/?max_results=2 | python -mjson.tool { "_items": [ { "_id": "517b88e4f84a4b15f756a1af", "_links": { "self": { "href": "localhost:5000/api/v1/users/517b88e4f84a4b15f756a1af/", "title": "user" } }, ... }, { "_id": "517b88e4f84a4b15f756a1b0", "_links": { "self": { "href": "localhost:5000/api/v1/users/517b88e4f84a4b15f756a1b0/", "title": "user" } }, ... ], "_links": { "next": { "href": "localhost:5000/api/v1/users/?max_results=2&page=2", "title": "next page" }, "parent": { "href": "localhost:5000/api/v1", "title": "home" }, "self": { "href": "localhost:5000/api/v1/users/", "title": "users" } } }

On Apr 26, 2013, at 11:32 PM, Richard Wackerbarth <rkw@dataplex.net> 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.

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.
I think that's reasonable.
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.)

On Apr 27, 2013, at 9:15 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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.
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.

Richard Wackerbarth writes:
Groupings of lists simply provides a "shorthand" for the description of characteristics which are common to the group.
You don't need to teach Grandma how to suck intensional vs. extensional Python eggs.
Ie, the advantage of being generic is that it's generic.
Note that "core" doesn't NEED the structure to function.
Of course not, the only structure we NEED is a tape that's lightyears long, and a finite automaton that Turing designed in the 40s IIRC. Sorry for the sarcasm (well, a little bit sorry), but in deciding on design principles we need to evaluate simplicity, practicality, etc from the point of view of the people involved.
The question is whether structure makes the program easier for users to use and for developers to create and maintain. 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 makes it easier to think about requirements and write code to satisfy them.
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"?
as the list/list-group identifier, we get the generic hierarchy as a byproduct.
No, that's not enough. 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.
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. Without use cases for the generality, it's hard to see the benefits. When do you expect the generality to be of use?
I have no clue what you're trying to express here. 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 use cases without significantly complexifying the job of serving the common case.
I don't see a simplification for the reasons expressed above.
What are the use cases for a more generic structure?

On Apr 28, 2013, at 11:15 AM, Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> wrote:
That makes it easier to think about requirements and write code to satisfy them. Not necessarily.
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.
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.
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.
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 argue that it simplifies the case that you mention because it provides a uniform way to deal with all of the aspects, especially the delegation aspects which are not addressed in the present scheme.
I don't see a simplification for the reasons expressed above.
What are the use cases for a more generic structure?

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.

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 <stephen@xemacs.org> wrote:

Richard Wackerbarth writes:
But here the limits apply to *principals*[1], not lists, AFAICS. Sure, you can record them on the lists, but you'll still have to check the principal's ID/authorization (presumably site admins can do anything they want, even to a list owned by a Bronze customer who can't do it for himself. Note how you repeatedly write "[principal] be allowed":
I could see this organization being usable in a case where a customer wants to have some Bronze-plan lists and some Gold-plan lists. However, I could also abstract "customer" as a principal which is a group of accounts with a common billing address. Then accounts would be authorized, and the customer would log in as an account-user as appropriate, rather than log in as a customer-user. The user interface could provide a su-like way to switch accounts of a single customer, and/or a sudo-like way to work with "foreign" accounts.
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.
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.
Footnotes: [1] A generic term covering users, groups of users, accounts, and in general "entities that can be authorized".

On Apr 28, 2013, at 9:58 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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 ...
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.
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.

Richard Wackerbarth writes:
You seem to be missing the point that "one size fits all", or in this case, one hierarchy, is not a flexible strategy.
Sorry, that's false, and there's plenty of evidence in the archives that I've acknowledged that point.
But "flexible" is not an absolute, not even if you're discussing female gymnasts. 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.
Sure. That's the main point of a generic model, sharing code to handle cases that are similar enough to handle with the same code.
However, I don't think it's true that they're that similar. By the principle of subsidiarity, there are things that a List Administrator does that a Domain Administrator normally shouldn't do (authorizing moderators). But there are others that both should be able to do (clearing queues of broken messages, removing legally objectionable messages from archives).
So to handle both attributes that are subject to subsidiarity and those that aren't, you need as much code as in the current model, *plus* in your model you need to make the code generic *and* provide rules for the existing use cases. That just doesn't sound like a bargain to me in the absence of a few plausible *and concrete* use cases that require more flexibility.
Steve

On Apr 28, 2013, at 11:59 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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 <role>. 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.

Richard Wackerbarth writes:
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).
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. That leads to ugly and unmaintainable code.
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. 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.)

On Apr 29, 2013, at 8:12 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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.
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.
Agreed. One purpose of a list hierarchy is to make it easier to specify and maintain these attributes.

Richard Wackerbarth writes:
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

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 <stephen@xemacs.org> wrote:

On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull <stephen@xemacs.org> 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.
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"

Richard Wackerbarth writes:
So are most religions, but for some reason they all have exceptions where the Power chooses not to perform miracles.
many of which involved reworking existing code to handle some changed conditions.
Of course you do. Anybody with five years of experience has run into that. But with decades of experience, surely you've also run into projects that never saw the light of day because the implementers overengineered Grand Designs which didn't address user requirements.
Mailman 2.1. I've seen no real reason to suppose we need more. What people repeatedly request on Mailman channels (in my, eminently fallible, recollection) is more *power* for existing administrator roles (viewing logs), more power for the user role (searching archives), and more intuitive UIs for both. Barry's design for Mailman 3 addresses those needs by making it a heck of a lot easier to experiment with additional UIs.
An example of a use case I don't like is the "Like" buttons (or something like that) the HyperKitty guys are putting in. Nobody has requested them on Mailman channels that I can recall. But social networks are booming, and any visit to YouTube will provide evidence that people do use those "Like" buttons, and comment on them. I have no ground to stand on there. I'm sure those buttons will be appreciated and used by lots of subscribers. That use case is valid, whatever my personal feeling is.
But I've never seen (IMEFR) a request for more flexibility in constructing an administrative organization for a Mailman site.
I am, at least, proposing a framework which would be able to address these issues.
My point is, "Don't tell me about theoretical issues. What use cases are you addressing?" If users aren't going to use your framework, there's no point in building it.
You're not listened if that's what it sounds like to you. I haven't once asked you for running code. I've asked you for examples of what Real Users[tm] might want to run the proposed code for.
If you want to build it with your own resources, I have no problem with that. If you want me to help, or if you want me to support your design to other developers (including GSoC interns), I need to know what it's for, besides addressing issues that I do perceive in software engineering theory, but not in Mailman practice.
Steve

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.)
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?
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
?

Richard Wackerbarth writes:
"ABCDEFG" is what? The list?
I think the short prefix /mailman/ should be reserved for traditional and anonymous requests. /mailman/rest_api/ or some such for the REST API.
This is what you mean by self-documenting? Presumably it returns not only the attribute names, but their ranges (types) and docstrings?
https://server.example.com/mailman/attribute/posting_address/test_list@examp... would return the URI representing the list
Why have you changed the order of components here?
https://server.example.com/mailman/attribute/posting_address/test_list@examp... might return test_list-join@example.com
Huh? This isn't a syntax error?

On Apr 27, 2013, at 2:42 AM, "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> wrote:
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 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.
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.
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_list@examp... might return test_list-join@example.com
Huh? This isn't a syntax error?
Probably is syntactically incorrect. The email address would need to be URL escaped.

Richard Wackerbarth writes:
"ABCDEFG" is what? The list?
Yes. But note that it is some pk provided by the list store.
"pk" ?
So "attribute/posting_address/test_list@example.com" is a query that means "give me a way to indicate this list"?
These URIs are pretty ugly. Surely we can do better?

On Apr 27, 2013, at 8:19 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
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.
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.

Richard Wackerbarth writes:
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.
These URIs are pretty ugly. Surely we can do better?
Perhaps we can. But we need to conform to the HAL framework style.
Well, I haven't studied it carefully, but the examples on Mike Kelly's pages are pretty enough.
From the consumer's point of view, yes, the links are discovered. But the producer constructs them.

On Apr 27, 2013, at 10:36 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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.

Richard Wackerbarth writes:
Being able to "write URIs by hand" is a violation of the HAL design because it locks the interface into a particular implementation.
Sorry, that's an un-Pythonic way to think. If HAL really requires URIs that only a machine can deal with, let's junk it. "If the implementation is hard to explain, it's a bad idea."
But I really don't think HAL requires that.

On Sat, Apr 27, 2013 at 6:34 AM, Richard Wackerbarth <rkw@dataplex.net>wrote:
The rules of good endpoint is very simple. * For first-class resources collections endpoint: <domain>/<api_prefix>/<version>/<collection name>/ e.g. http://list.mailman.org/api/v1/users document endpoint: <domain>/<api_prefix>/<version>/<collection name>/<doc_id>/ e.g. http://list.mailman.org/api/v1/users/ID1234567/ * Don't use path as tools of deep query, use query string for query e.g. http://list.mailman.org/api/v1/users/?subscriptions="mailing_list_abc" * Use hyperlinks for references between first-class resources in documents: e.g. curl localhost:5000/api/v1/users/?max_results=2 | python -mjson.tool { "_items": [ { "_id": "517b88e4f84a4b15f756a1af", "_links": { "self": { "href": "localhost:5000/api/v1/users/517b88e4f84a4b15f756a1af/", "title": "user" } }, ... }, { "_id": "517b88e4f84a4b15f756a1b0", "_links": { "self": { "href": "localhost:5000/api/v1/users/517b88e4f84a4b15f756a1b0/", "title": "user" } }, ... ], "_links": { "next": { "href": "localhost:5000/api/v1/users/?max_results=2&page=2", "title": "next page" }, "parent": { "href": "localhost:5000/api/v1", "title": "home" }, "self": { "href": "localhost:5000/api/v1/users/", "title": "users" } } }

On Apr 26, 2013, at 11:32 PM, Richard Wackerbarth <rkw@dataplex.net> 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.

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.
I think that's reasonable.
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.)

On Apr 27, 2013, at 9:15 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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.
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.

Richard Wackerbarth writes:
Groupings of lists simply provides a "shorthand" for the description of characteristics which are common to the group.
You don't need to teach Grandma how to suck intensional vs. extensional Python eggs.
Ie, the advantage of being generic is that it's generic.
Note that "core" doesn't NEED the structure to function.
Of course not, the only structure we NEED is a tape that's lightyears long, and a finite automaton that Turing designed in the 40s IIRC. Sorry for the sarcasm (well, a little bit sorry), but in deciding on design principles we need to evaluate simplicity, practicality, etc from the point of view of the people involved.
The question is whether structure makes the program easier for users to use and for developers to create and maintain. 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 makes it easier to think about requirements and write code to satisfy them.
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"?
as the list/list-group identifier, we get the generic hierarchy as a byproduct.
No, that's not enough. 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.
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. Without use cases for the generality, it's hard to see the benefits. When do you expect the generality to be of use?
I have no clue what you're trying to express here. 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 use cases without significantly complexifying the job of serving the common case.
I don't see a simplification for the reasons expressed above.
What are the use cases for a more generic structure?

On Apr 28, 2013, at 11:15 AM, Stephen J. Turnbull <turnbull@sk.tsukuba.ac.jp> wrote:
That makes it easier to think about requirements and write code to satisfy them. Not necessarily.
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.
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.
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.
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 argue that it simplifies the case that you mention because it provides a uniform way to deal with all of the aspects, especially the delegation aspects which are not addressed in the present scheme.
I don't see a simplification for the reasons expressed above.
What are the use cases for a more generic structure?

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.

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 <stephen@xemacs.org> wrote:

Richard Wackerbarth writes:
But here the limits apply to *principals*[1], not lists, AFAICS. Sure, you can record them on the lists, but you'll still have to check the principal's ID/authorization (presumably site admins can do anything they want, even to a list owned by a Bronze customer who can't do it for himself. Note how you repeatedly write "[principal] be allowed":
I could see this organization being usable in a case where a customer wants to have some Bronze-plan lists and some Gold-plan lists. However, I could also abstract "customer" as a principal which is a group of accounts with a common billing address. Then accounts would be authorized, and the customer would log in as an account-user as appropriate, rather than log in as a customer-user. The user interface could provide a su-like way to switch accounts of a single customer, and/or a sudo-like way to work with "foreign" accounts.
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.
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.
Footnotes: [1] A generic term covering users, groups of users, accounts, and in general "entities that can be authorized".

On Apr 28, 2013, at 9:58 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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 ...
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.
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.

Richard Wackerbarth writes:
You seem to be missing the point that "one size fits all", or in this case, one hierarchy, is not a flexible strategy.
Sorry, that's false, and there's plenty of evidence in the archives that I've acknowledged that point.
But "flexible" is not an absolute, not even if you're discussing female gymnasts. 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.
Sure. That's the main point of a generic model, sharing code to handle cases that are similar enough to handle with the same code.
However, I don't think it's true that they're that similar. By the principle of subsidiarity, there are things that a List Administrator does that a Domain Administrator normally shouldn't do (authorizing moderators). But there are others that both should be able to do (clearing queues of broken messages, removing legally objectionable messages from archives).
So to handle both attributes that are subject to subsidiarity and those that aren't, you need as much code as in the current model, *plus* in your model you need to make the code generic *and* provide rules for the existing use cases. That just doesn't sound like a bargain to me in the absence of a few plausible *and concrete* use cases that require more flexibility.
Steve

On Apr 28, 2013, at 11:59 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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 <role>. 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.

Richard Wackerbarth writes:
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).
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. That leads to ugly and unmaintainable code.
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. 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.)

On Apr 29, 2013, at 8:12 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
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.
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.
Agreed. One purpose of a list hierarchy is to make it easier to specify and maintain these attributes.

Richard Wackerbarth writes:
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

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 <stephen@xemacs.org> wrote:

On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull <stephen@xemacs.org> 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.
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"

Richard Wackerbarth writes:
So are most religions, but for some reason they all have exceptions where the Power chooses not to perform miracles.
many of which involved reworking existing code to handle some changed conditions.
Of course you do. Anybody with five years of experience has run into that. But with decades of experience, surely you've also run into projects that never saw the light of day because the implementers overengineered Grand Designs which didn't address user requirements.
Mailman 2.1. I've seen no real reason to suppose we need more. What people repeatedly request on Mailman channels (in my, eminently fallible, recollection) is more *power* for existing administrator roles (viewing logs), more power for the user role (searching archives), and more intuitive UIs for both. Barry's design for Mailman 3 addresses those needs by making it a heck of a lot easier to experiment with additional UIs.
An example of a use case I don't like is the "Like" buttons (or something like that) the HyperKitty guys are putting in. Nobody has requested them on Mailman channels that I can recall. But social networks are booming, and any visit to YouTube will provide evidence that people do use those "Like" buttons, and comment on them. I have no ground to stand on there. I'm sure those buttons will be appreciated and used by lots of subscribers. That use case is valid, whatever my personal feeling is.
But I've never seen (IMEFR) a request for more flexibility in constructing an administrative organization for a Mailman site.
I am, at least, proposing a framework which would be able to address these issues.
My point is, "Don't tell me about theoretical issues. What use cases are you addressing?" If users aren't going to use your framework, there's no point in building it.
You're not listened if that's what it sounds like to you. I haven't once asked you for running code. I've asked you for examples of what Real Users[tm] might want to run the proposed code for.
If you want to build it with your own resources, I have no problem with that. If you want me to help, or if you want me to support your design to other developers (including GSoC interns), I need to know what it's for, besides addressing issues that I do perceive in software engineering theory, but not in Mailman practice.
Steve
participants (4)
-
Richard Wackerbarth
-
Stephen J. Turnbull
-
Stephen J. Turnbull
-
Xu Wang