Re: [Mailman-Developers] Introductory mail
On Thu, Jan 22, 2015 at 12:58 PM, Pranjal Yadav godricg...@gmail.com wrote: Hello I'm a programming enthusiast and recently started working in python about 6 months back, I have had experience in cryptography and many machine learning techniques. I started reading about mailman few weeks back and I have setup a local and server dev env successfully. I also learned about previous year's GSOC project and I can see mailman core is already ported to ver 3.4 however potorius / hyperkitty / mailman.client needs to be done. Also test suite would be interesting work to couple with all this. I would like to know if these 2 projects can be coupled for this year's work or not? Apart from that I also found few bugs while setting up env which was mainly due to (var) folder creation while running mailman server from different locatin serving various instances. It seems unless I do it from path/to/mailman it returns an error. I will go through the code in over next few weeks and till then I can expect a reply for above projects. I guess this is not a bug. There is a setting in the mailman.cfg that tells mailman where to put in the var directory. Look for var_dir under [paths.dev] PS : The documentation for mailman setup is outdated I guess, reported that to @maxking -- Pranjal Yadav Final Year Undergraduate Student Department of Metallurgical and Materials Engineering IIT Kharagpur ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/rajeevs1992%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Code refactored as per feedback
Hi, As per the feedback from Steve, I have made changes to the code in following areas - The get_listing method has been moved to the lib/utils and has been rebuilt in a class *independent* way, and it works as good as before. - The connection checking has been moved to the connect function, without the need of making a database call, by checking the Mailman version using client.system - The addition of CLI colors has been made more generalized by making it a module level variable, with colors stored in a separate file. - Removed class attributes from Filter class, and changed them to arguments - All files now have a header acknowledging the support of Google, along with the names and contacts of mentors. Here is a link to the r70 http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/70 I will be improving the error handling, as mentioned in the comments, with the next revision. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
Hi Steve On Fri, Aug 8, 2014 at 10:04 AM, Stephen J. Turnbull turnb...@sk.tsukuba.ac.jp wrote: Rajeev S writes: ... Sure, but that's not particularly important since actually it will be the mailman.client directory when you integrate it, and (especially after Barry's post just now) I'm pretty sure Barry intended the client to live inside the mailman package. Ok. I will leave it as it is. Further, The mmclient.py *should have* a callable function for it to work as a module entry point (a.k.a shell command), when installed through `python setup.py install`. The created executable does `import` the mmclient ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
Hi Steve, On Thursday 07 August 2014 12:00 PM, Stephen J. Turnbull wrote: Rajeev S writes: I feel that it will make the code cluttered. Since the CLI code is independent of the rest of mailman client, won't it be better to maintain the CLI code in a separate folder, as it is now? Of course. I didn't explain myself well. What you have now is mailman/ -+- client/ -+- _client.py +- docs/ +- tests/ +- cli/ -+- client.py +- core/ +- docs/ +- lib/ +- tests/ The above tree is wrong, this is the current directory structure mailmanclient/ -+- _client.py +- docs/ +- tests/ +- cli/ -+- mmclient.py +- core/ +- docs/ +- lib/ +- tests/ +- client/ That is, the cli/ directory lives directly inside the mailmanclient directory. I don't see where. In Filter, you have: class Filter(): key = None value = None operator = None data_set = [] utils = Utils() def __init__(self, key, value, operator, data): self.key = key self.value = value self.operator = operator self.data_set = data So as soon as you instance a Filter, __init__() creates instance attributes which shadow the class attributes (except utils). I don't see any references to Filter.attr or to super(), so I don't see how you can be using the class attributes. Now I get it! Will fix that. Now that the connection part is managed by a single function (Utils.connect), I will move the connection checking part to that function. OK. The connection can be checked without using a database query by trying to invoke the `client.system` , at a single place. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
Hi Steve, On Wednesday 06 August 2014 12:14 PM, Stephen J. Turnbull wrote: Tree organization - I don't think the CLI should be buried several levels deep in the source. The mailman.client package is really a collection of services, and the CLI should be at the same level in some sense. I feel that it will make the code cluttered. Since the CLI code is independent of the rest of mailman client, won't it be better to maintain the CLI code in a separate folder, as it is now? All file references below are relative to mailman.client/src/mailmanclient/cli. Is there any code outside of this directory that is yours? I have made modifications to setup.py, other than that, no. It's hard to recognize which files are part of this project. This should be reflected in header comments and/or module docstrings. I think that these files should also acknowledge support from Google, and provide contact addresses (yours and mentors'). There should be a README file of some kind at the top of your subtree, or perhaps a section in the mailman.client top level README. Will add those information in the headers by next revision. mmclient.py --- This file is part of your 2014 GSoC project, and not inherited from mailman.client, right? Yes. I created this file. I think there should be some comments in this file, for example explaining why you have what seem to be two different REPLs (c.run() and s.cmdloop()) invoked. It's not clear to me why you define a separate main() function in this script -- it doesn't make sense to import it as a module. I was not quite familiar with using the python setuptools and I assumed that such a format was necessary to specify module entry points in setup.py. I have now removed the main function from mmclient.py docs Run a spellchecker on these files (I saw at least one typo). Yikes! Sorry about that. Fixed at least ten of them :) Generally they look very good: clear and complete. lib --- In lib/utils.py, I think there should be a more flexible way to specify the emphasis and so on. This is especially important for color-blind and partially-blind users. For now you don't need to provide a user interface, but I'd be happier if the control sequences were kept in module-level variables and interpolated into the messages using %-formatting or str.format. (Note that if you wanted to, you could use HTML tags in such variables. Eg, many Qt4 and Qt5 widgets that can display text respect HTML tags in display.) Sure. Will add that in the next revision. In lib/utils.py class Filter, what are the class attributes for? They are not used or useful. The Filter class is used to filter out objects meeting a certain condition specified by a key, op [aka operator] and value. The filtering process works by iterating through each element in the data_set and removing the objects that do not match the criterion, from a copy of the data_set. The data_set cannot be used alone, as removing entries from a running `for i in list` loop can cause the loop to misbehave. The filtered copy is finally returned. All the class attributes are being used in the process described above. core In core/domains.py, you instantiate the Domain list then delete it, commenting it as testing the connection. Why does this need to be done in the constructor? Although Domain doesn't currently provide any services that can be accomplished without a database query that I noticed, so the check doesn't really hurt, it could. (For example, validating domain names against the syntax recommended by RFCs 822 and 1034 for mail domains.) The same kind of service would apply to list names. It's also possible that there is a transient interruption that is resolved before any actual work is done, but this check would make the script fail. Now that the connection part is managed by a single function (Utils.connect), I will move the connection checking part to that function. I will try to come up with a better way to check for the connection, so that the mentioned possible issues can be put away. BTW, I believe there is no need to assign self.client.domains to a variable (the Python optimizer isn't that smart AFAIK). Even if you do assign, there's no need to delete the variable, as the value will be GC'd after exiting the constructor. IIRC, del doesn't guarantee that the object will be GC'd any time soon, just DECREF's it. Those lists were not stored into variables until some revisions back. I got a random thought that it is a bad practice , and replaced that code with a variable assignment. It was then when my PEP8 checker returned an error stating the presence of an unused variable, which I solved by deleting the assigned variable! Assuming that an HTTPError means that the operation failed in an expected way (eg, deleting a nonexistent domain) is unacceptable. In particular, the transaction may fail if Mailman is stopped. The code must check
[Mailman-Developers] [CLI Project] Added Backup and Restore Tool
Hi, As the Summer of Code period comes to an end, I am one more step closer to completion of the features mentioned in my proposal. I have built the initial version of the backup and restore tool, that currently supports backup and restore of a sqlite Mailman Instance, by archiving the var_dir to a zip archive. Further, the CLI is now installable using `python setup.py install` and the `mmclient` command is added to the `bin`. So the commands can now begin as `mmclient ...` I have also replaced the `in list` filter present in the `show` commands, with a regular expression matcher for better usability of the command. I have begun code scrubbing and my primary aim will be improving the documentation and more importantly, continue writing unit tests from where I left off. I expect to complete the tasks by the suggested pencil down date [11/08/2014] and spend the last week on improving the code structure, if possible anywhere. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [CLI Project] Added Backup and Restore Tool
On Tuesday 05 August 2014 12:27 AM, Rajeev S wrote: Hi, As the Summer of Code period comes to an end, I am one more step closer to completion of the features mentioned in my proposal. I have built the initial version of the backup and restore tool, that currently supports backup and restore of a sqlite Mailman Instance, by archiving the var_dir to a zip archive. Further, the CLI is now installable using `python setup.py install` and the `mmclient` command is added to the `bin`. So the commands can now begin as `mmclient ...` I have also replaced the `in list` filter present in the `show` commands, with a regular expression matcher for better usability of the command. I have begun code scrubbing and my primary aim will be improving the documentation and more importantly, continue writing unit tests from where I left off. I expect to complete the tasks by the suggested pencil down date [11/08/2014] and spend the last week on improving the code structure, if possible anywhere. Sorry, I missed to mention that I have committed and pushed the r69 that carries the above changes. Here is a link to the r69 http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/69 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Added export to CSV feature
Hi, I have pushed r68 that adds the export to CSV feature to the mailman command line tools. Usage ./mmclient show user -v --csv path/to/file.csv ./mmclient show list -v --csv path/to/file.csv ./mmclient show domain -v --csv path/to/file.csv The r68 further adds the support for white spaces in object names. The corresponding regular expression has been modified in all parsers. create user with `email` = `a...@b.com` and `display_name` = `Foo Bar` and `password` = `abcde` http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/68 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Command Parsing method switched to YACC
Hi, I have been a bit unhappy about the regular expression approach for command validation and array processing for command parsing to get the arguments. So I have decided to switch to the conventional and right method to do it, using the Lex-YACC duo, using the PLY module. I have already ported half of the command's processing to PLY and it works great. I will be completing the rest of commands by 25/07/2014, I expect to push r67 by 26/07/2014. I have set a soft deadline for the tasks mentioned in my proposal as 06/08/2014, Google deadline being 11/08/2014. Remaining tasks include, 1. Backup and restore tool, 2. Export data to CSV or Text 3. Man Pages 4. User Documentation -- Docstring improvement and regularization 5. Writing Installation routines for new modules All tasks except `1` are easy. So my primary focus for the next week(s) would be the backup and restore tool. Post the above mentioned soft deadline, I would be writing the unittests for the new units. I had postponed the unit test writing as it consumed lot my time. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Update Preference Command added
Hi, I have pushed two revisions, r65 (19/07/2014) and r66 (20/07/2014). Here are the changes under r65: - Changes the command preprocessing workflow - Command processing invoked by using a decorator. - Removes redundant code in present in the shell, for example, at the auto complete functions. - error reporting brought to single point, as in the command tools - removes the override on the cmd.parseline function, so that the autocomplete functions work flawlessly - Commands are now processed just before the actions are performed, hence providing maximum control. http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/65 Here are the changes under r66: - Introduces the `update preference` command for Mailman shell. - Regular expression based syntax verification for all commands. The regular expressions are read from the config.ini using the ConfigParser. The regex based verification helps to avoid validations when the commands are being processed for execution. - Adds docstrings for all command methods - Upon command failure or syntax error, command help and usage are displayed http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/66 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Completed Subscribe and Unsubscribe commands
Hi, I have completed and pushed the subscribe and unsubscribe command support as r64. This adds two commands to the shell subscribe users a...@b.com f...@bar.com to l...@domain.org unsubscribe users a...@b.com f...@bar.com from l...@domain.org The next revision, r65 will refactor code to reduce redundant code at many functions and betterment of error and exception handling and reporting. The revision 65 will also include Preferences related actions. http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/64 *Regards,Rajeev S* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Create object and Delete object functionalities
Hi, I have pushed 2 revisions r62 (10/07/2014) and r63 (12/07/2014) that implement the create object and delete object functionalities. A snapshot of the new revisions: 1. The support for automatic implicit filtering based on reserved environment variables like domain has also been implemented. Now, the user can set a reserved variable, say domain, and perform actions on the shell without specifying the domain filter in the future commands. See docs for examples and more explanation. 2. Create actions use the same functions as of the command tools. The required arguments are collected from user and user is promptly notified about the required arguments, in case if any of them are missing. 3. Delete commands use the syntax of the show command, and hence support the same level of filtering as in show command. 4. The support for turning shell environment on and off has been implemented. 5. All the commands now support auto complete feature, up to the first argument. The next set of tasks are subscription related tasks, which will be completed by Monday,14th July. http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/62 http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/63 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Initial Commit on Command Line Shell
Hi, I have pushed the r61 [1], which makes it the first commit on the Command Line shell. As Steve suggested, I have also modified the CL tools (and shell) to support both singular and plural instance names using a naive function, that can be replaced with a prefix matching procedure, if necessary. As for the shell, it currently supports the `display objects` functionality using the `show` clause. The `show` clause supports three kinds of filters, equality, in_list and a regular expression filter. Also, r61 adds a basic version shell environment functionality, which can be used to store variables that can be reused in the queries. The feature `setting of mailman object names in the environment and using them without explicitly specifying them the queries` is yet to be built and will be a part of r62, which I expect to complete by Wednesday (09/07/2014). r62 will also include the create functions for the mailman objects. Currently, the shell supports only conjunctions in clauses. Queries can contain any number of filters specified using the conjunctions. A few sample queries that are currently supported by the shell set domain domain.org show lists where mail_host = $domain show lists where mail_host = $domain and f...@bar.com in moderators show users where display_name like .*foo show domains unset domain I have also updated the docs for the same. r62 will contain: 1. Automatic filtering of results based on predefined environment variables like domain, list and user 2. `Create object` queries, a quite straight forward one. 3. `Delete object` queries 4. Turn on/off the environment variables Footnotes [1] http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/61 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Portioning Commands as Singular or Plural
Hi, A modification has been suggested for the Command line tools in an IRC discussion with Abhilash. It was suggested that, to make commands more intuitive, the commands be partitioned into singular and plural as per the scale of the action performed. For example, In the current scenario ./mmclient show user //Lists all users in the system ./mmclient show user f...@bar.com //Describes the user f...@bar.com Usage after the suggested change ./mmclient show users //Lists all users in the system ./mmclient show user f...@bar.com //Describes user f...@bar.com The commands surely do become more intuitive and make more sense, but this has a negative,the number of commands almost doubles. Further, Use cases like delete, subscribe and unsubscribe support actions on multiple users simultaneously. Currently, the following commands are valid ./mmclient delete user a...@b.com b...@c.com d...@e.com ./mmclient delete user a...@b.com If the suggested change is applied, the following commands must work ./mmclient delete users a...@b.com b...@c.com d...@e.com ./mmclient delete user a...@b.com both of which perform the same action, using the same procedure. Another option might be to use *only plurals*, which seems OK for most of the use cases. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Support of filtering of objects in Command Shell
Hi, Now the mid term evaluations are done, I would be building the command line shell, as planned. I would like to present how I would like to tackle the requirement at hand. As mentioned in my proposal and the most logical approach, all the common functionalities between the shell and the already built command line tools would use the same classes, the ones built for the command tools. As this is a command shell, I wish to give it a SQL like feel. However, The SQL commands SELECT, INSERT INTO do not look nice in Mailman context, as we are dealing with objects and not tables. I would be using the object related terms like SHOW, CREATE etc for the respective actions. However, I would like to discuss about the support for the WHERE clause by the shell. The WHERE clause is not mentioned in my proposal, but I feel that this feature ought to be in the project. If the commands require to support a WHERE clause, as SQL does, For example, show users where display_name = 'foo' and subscribed_list_ids contains = 'l...@domain.org mailto:%27l...@domain.org' The steps involved in processing a command with a WHERE clause would be 1.Parse the command 2.Filter the results from the database 3.Perform the action using the command line tool methods if possible else write a new procedure. For the Step 2, there are two approaches in hand: 1.Use the Storm library to query the database directly, as mailman core does. 2.Use the REST API By using the first approach, a good performance improvement is achieved, by leaving the data filtering to database engine. But this limits the usability of of the CLI to the system in which the mailman database exists, as the remote connections to DB servers are usually disabled. By using the second approach, the performance is bad, as it requires a normal python `for` loop that compares the the results one by one. However, this approach might be easier in case that the mailman installation be managed remotely, if its OK to enable the REST API to accept connections from remote machines.(I believe this is currently not supported/disabled by default.) By building the WHERE clause, its costlier to reuse the command line tools methods in many use cases, like delete, subscribe etc. Further, as I have already mentioned to Abhilash, it demands more time. I am not sure if that will fit into GSoC time frame. I am confident that I can make significant progress, but not sure if it can be 'completed'. Also, I am fine on completing it even after GSoC. So, the final question is, Should the CLI support filtering using the WHERE clause? Or should I proceed as per my proposal, building a basic Mailman shell and leave the rest to be completed in future? ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Preference management commands added
Hi, As promised, I have completed the preference related commands and pushed it as revision 60 [1]. The preferences form a new scope, along with user, domains and lists. There are 2 commands associated with the `preference` scope. 1.Show Preference ./mmclient show preference [scope] [scope_args] [key] That is, to view a preference of a list member ./mmclient show preference member --email a...@b.com --list l...@domain.org receive_own_postings 2. Update Preference Similar to the above command ./mmclient show preference [scope] [scope_args] [key] [value] ./mmclient show preference member --email a...@b.com --list l...@domain.org receive_own_postings true The supported preference scopes are global [2] user --email address --email member --email --list Also, the command scope resolution code in cmdparser.py, which was repeated once per scope, has been replaced with a better and faster approach. Footnotes: [1] http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/60 [2] Upon updating/editing the global preferences, a `HTTP Error 405 : Method not allowed is raised`. I tried as sudo but still no good. Is that a mailman bug or a design decision? ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project]Commands for adding Moderators and owners
Hi, I have pushed r59 (In fact, 2 days before) which adds commands to perform the following actions - Add moderators ./mmclient add-moderator list l...@domain.org --user a...@b.com b...@c.com d...@e.com - Add owners ./mmclient add-owner list l...@domain.org --user a...@b.com b...@c.com d...@e.com - Remove Moderator ./mmclient remove-moderator list l...@domain.org --user a...@b.com b...@c.com d...@e.com - Remove Owner ./mmclient remove-owner list l...@domain.org --user a...@b.com b...@c.com d...@e.com All the above commands support an extra --quiet flag to suppress the action feedback message. http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/59 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Describe instance and Subscription features
Hi, I have completed the describe instance feature and the subscription features for the CLI. I have pushed the changes as r58.[1] The describe feature is implemented as an extension to the `show` command. This feature adds 3 new usages for the `./mmclient show` action, apart from the previous functionalities. ./mmclient show user f...@bar.com [2] ./mmclient show list li...@domain.org [3] ./mmclient show domain domain.org [4] The subscription features are built as mentioned in my previous mail ./mmclient subscribe user us...@foo.com us...@bar.com --list l...@domain.org ./mmclient unsubscribe user us...@foo.com us...@bar.com --list l...@domain.org The commands support usage with either a single user or multiple users. [1] http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/58 [2] https://gist.github.com/rajeevs1992/3ca077fd7d1a5a1d5729 [3] https://gist.github.com/rajeevs1992/15f69f5bfdbda52c4e36 [4] https://gist.github.com/rajeevs1992/49fbe250ab9e1f254c11 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project]Developed the describe instance feature
Hi, I have completed the `describe instance` feature for the list object. I herewith attach the sample output of the command. https://gist.github.com/rajeevs1992/3ca077fd7d1a5a1d5729 The describe feature is triggered when the `show` action is supplied a object name of the corresponding domain. ./mmclient show list li...@domain.org Further, the CLI can easily be extended to support an independent sub command `describe` to perform the same action, *if necessary*. ./mmclient describe list li...@domain.org The describe feature is intended just for getting a snapshot of the object, in one shot. I will be completing the same for rest of the objects and pushing the next revision by 17/06/2014,Tuesday, as I will be away from computer this weekend. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman CLI Project] Subscription and Membership related Actions
This is always possible subscribe users us...@foo.com us...@bar.com us...@bar.com --list l...@domain.org Hi, I have built to features, subscribe and unsubscribe users, as described above *subscribe users us...@foo.com us...@bar.com us...@bar.com --list l...@domain.org* and *unsubscribe users us...@foo.com us...@bar.com us...@bar.com --list l...@domain.org* The command prints a success message on successful completion of action else prints an error message and continues execution. These feedback messages can be suppressed by using a `--quiet` switch. subscribe users us...@foo.com us...@bar.com us...@bar.com --list l...@domain.org us...@foo.com subscribed to l...@domain.org us...@foo.com subscribed to l...@domain.org us...@foo.com subscribed to l...@domain.org The commands accept one or more user emails as arguments. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [Mailman CLI Project] Subscription and Membership related Actions
On Fri, Jun 6, 2014 at 5:19 PM, Abhilash Raj raj.abhila...@gmail.com wrote: I think it would be more intuitive to have this command in list scope rather than user scope. And anyway list scope must have a command to list all subscribers. Could it be used somehow to subscribe or unsubscribe more than one user? If it was like `subscribe list l...@domain.org --user/users user1/user1,user2,user3`. Or maybe some other way to do it in user scope itself? This is always possible subscribe users us...@foo.com us...@bar.com us...@bar.com --list l...@domain.org ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [Mailman CLI Project] Subscription and Membership related Actions
Hi, The next set of tasks for the coming weeks, before the mid term evaluation, are mostly subscription and membership related actions for the CLI. The various actions that are to be implemented are 1. Show members of a list The `list members of a list` feature is currently available as a part of the users module, that takes list name as an argument. show user –list l...@domain.org This does not print the names of the list owners and moderators who are not members of the list by default. They can be added to the list by appending the `list.owners` and `list.moderators` to the member list. Is there a necessity of a new command under the `list` scope that does the same function? show-members list l...@domain.org 1. Subscribe/Unsubscribe users from a list The commands suitably belongs to the user scope subscribe user f...@bar.com –list l...@domain.org unsubscribe user f...@bar.com –list l...@domain.org 1. Add/remove owners/moderators These commands come under the list scope add-owner list l...@domain.org –user a...@b.com remove-owner list l...@domain.org –user a...@b.com add-moderator list l...@domain.org –user a...@b.com remove-moderator list l...@domain.org –user a@b. a...@b.comcom and a pair of commands to list the owners and moderators show-moderators list l...@domain.org show-owners list l...@domain.org 1. Edit/Set list settings List preferences can be set or modified using edit list l...@domain.org –key KEY –value VALUE 1. Setting membership preferences set preference –key KEY –value VALUE Discussions on placing a `domain` attribute to this command have been done, but I doubt whether a decision was made. I list below a possible usage set preference –key KEY --value VALUE [--global/--user USER /--address ADDRESS] 1. Describe instance Describe instance can be used to display the details of an instance, like settings and preferences. This can be achieved by extending the `show` command of each instance, by passing a key to the specific instance, like show list l...@domain.org show user f...@bar.com show domain domain.org The details available for the object `user` addresses created_on display_name preferences self_link subscribed lists, with role user id Details available for domain base_url contact_address description show lists mail_host url_host Details available for object list list_id list_name mail host members moderators owners pending requests settings The above details can be displayed in groups, with appropriate group headings. BTW,I have pushed the r57 that adds the unit tests for the `lists`. The unit tests for the `users` will be a part of the next revision, r58. Apart from that, I would like to add the `describe instance`, `subscribe/unsubscribe' features for the r58. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [CLI Project] Introduced Unit tests to CLI
On Mon, Jun 2, 2014 at 11:53 AM, Abhilash Raj raj.abhila...@gmail.com wrote: Hi Rajeev, Rajeev S rajeevs1...@gmail.com wrote: Thanks for considering my suggestion. I think you don't need to create a sub-module for each scope inside `tests` module. It should be simpler like `/tests/test_domain.py` and all the tests related to domains should reside inside that. You can add multiple test-cases for Domain like add, delete or whatever inside that single test_domain.py. I was in an idea to follow the one class per file style, especially when the classes tend to grow large in size as in the tests.(It was mentioned in the Barry's style guide, and so is a common coding guideline.) Should I change that? I see that you parsing the configuration to return a `mailmanclient.Client()` object twice, once in cmdparser.py and second time in`/lib/mailman_utils.py`. I don't understand why? Can cmdparser.py not use the `MailmanUtils.connect()` method? cmdparser.py takes the login credentials from the command line, and not the config.ini. config.ini, as of now, is just for the testing stuff. Here :/src/mailmanclient/cli/core/domains.py#L32 docstrings should be immediately after the `def` line, there should not be a empty-line in between them. Here: /src/mailmanclient/cli/core/users.py#L41 you can use upto 80chars in docstrings too before introducing a line break. Also if you are following the convention of specifying the parameter of a function in docstring, add a `:type param: foo` for each parameter too. It helps sphinx in generating better documentation. See this: https://pythonhosted.org/an_example_pypi_project/sphinx.html Fine.Will fix with the next revision. Everything else looks nice. Thank you! ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [CLI Project] Introduced Unit tests to CLI
Hi, As per Abhilash's comment to follow the TDD, I have covered the test cases for the `domain` scope. I know that TDD requires to write tests before implementation. However, I believe that it's not a good idea to postpone test cases for the existing units further. Also, I would like to thank Abhilash for the comment, before its too late to begin writing the tests. I have pushed the r56 that includes the test scripts. I have also done some significant refactoring on the code this weekend, to facilitate easy usage with the unittest package and to make the code more cleaner. The refactoring mainly includes imposing the of DRY principle -- moving repetitive code to the lib/* directory. As an end note, this is a hefty revision. :) http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/56 Thank You! ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
Hi, I have made more additions to the CLI, like the `delete` command and the `user` scope. Following is the list of changes brought about 1.Introduce User scope Actions supported by User scope currently are create, show and delete. show users, like other scopes, supports verbose and no-header flags. However the detailed listing of users is not quite effective as most of the fields are lists rather than single valued attributes. The non detailed version prints one of the email ids of each user. The show list command takes an optional argument list name that gives the users who are members of the list. 2.Introduce a cli/lib directory, to store procedures common across the application. The directory is to hold the procedures and classes that are reused among scripts. It currently holds a class that is used to colorize the output printed on the terminal. 3.Updated and improved docs/using.txt. It was obsolete in r54. 4.Added delete action for all objects The action is confirmed by a question to user, which can be overridden by a --yes switch. I will be committing and pushing r55 tonight (30/05/2014 around 16:30 UST, I am away from the computer right now). As mentioned by Steve and agreed by Barry, I too believe that, in the scenario of the CLI multiple confirmations won't be necessary. In a situation in which such multiple confirmations come necessary, I believe that the commands will be better if the confirmations are replaced by switches. I agree that an override for the confirmation message is necessary so that the CLI commands can be used in scripts and I would like to follow Barry's suggestion of using a `--yes` or `--force` switch. (Isn't --force more common than --yes, as in `rm -f` ?) About the create domain suggestion, Is the follow up question on `*create domain*`, upon missing domain, such a bad idea? A user already can `add a domain` by using the web interface. If that is not ambiguous, neither is this, right? However I see this issue, if a newbie user types in an email address in place of the list name, probably on misreading the command format, he would end up creating a domain for his mail provider. *$./mmclient create list --help* *Creates the list l...@domain.org l...@domain.org* *$./mmclient create list u...@gmail.com u...@gmail.com* *The domain gmail.com http://gmail.com does not exist.Create one?[y/n] y* *$* @Abhilash I have written unittests for methods like connect and create, but have to refine them more. Hence the tests won't come up in this revision. Also, I would like to ask how the tests should be triggered. Should there be a `mmclient test` with a set of possible switches like `all` ,`domain`, `list`, `user` etc? Or should the customary `python setup.py test` be used? I also propose to build a a *`describe user`* command that gives a detailed profile of the user. Verbose listing using tables is not so effective users as most of the attributes are lists. Thanks! ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
On Friday 30 May 2014 07:09 PM, Abhilash Raj wrote: On Fri, 30 May 2014 18:12:18 +0530 Rajeev S rajeevs1...@gmail.com wrote: I agree that an override for the confirmation message is necessary so that the CLI commands can be used in scripts and I would like to follow Barry's suggestion of using a `--yes` or `--force` switch. (Isn't --force more common than --yes, as in `rm -f` ?) No, as I think, `--yes` and `--force` or `-f` have different use cases. For conformations `--yes` is used most of the times, it says 'hey I know you are going to ask this question and my answer would be yes'. While `--force` is to actually *force* any operation that cannot be completed otherwise. Ok. I will go with the --yes. Good to hear that. Did you give TDD a try? Not yet, I wrote a few test cases for the existing units using python untitest. I will try to focus on following TDD for the next set of units. Also, I would like to ask how the tests should be triggered. Should there be a `mmclient test` with a set of possible switches like `all` ,`domain`, `list`, `user` etc? Or should the customary `python setup.py test` be used? You can use `nose2` for that, like mailman does. It automatically discovers all the tests in directories specified and runs them. Ok. What detail profile are you talking about? Apart from addresses and name(optional) does mailman store any other data about a user? You can show the lists he is subscribed to, but `describe user` may not be an appropriate command for that. Maybe you can add it in users scope itself like `mmclient user a...@b.org --list-subscriptions` Others may have different thoughts though. The following are the details that are available for a user 1.Addresses 2. Subscriptions (3. Subscription list id's) 4.Preferences 5.Self link @all BTW I have pushed r55. http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/55 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
Hi Barry, Although I haven't had time to go through the code, I'm liking what I'm seeing here on the mailing list. Just a quick comment. [...] Ideally, because this is a command line tool aimed and users, there should be a manpage for mmclient. Fortunately, it's *really* easy to write manpages in reST with Sphinx. Sure it is necessary. And writing the man page is mentioned in my proposal as a project deliverable. http://sphinx-doc.org/builders.html#sphinx.builders.manpage.ManualPageBuilder And since examples never hurt: http://tinyurl.com/pwa2dfh Thanks for the links. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
On Tuesday 27 May 2014 12:27 PM, Abhilash Raj wrote: Rajeev S rajeevs1...@gmail.com wrote: Both of these options looks clean to me as a user. So if I am right you have completed * Listing of domains * Listing of mailing lists(filtered by domain also) * Creating domains * Creating mailing lists Right? Since this tool is meant for the users, you should write better documentation. Like in using.txt#39 what does long listing mean? What does `--verbose` do for listing a domain? Or even for listing all the lists? As I understand using.txt is more of a command reference than documentation? Are there only these two options for lists and domains? What about editing any list? Adding and removing user roles will be possible after you have create the `user` scope but editing of other parameters can be done? No, there are more options for lists and domains, many of which are dependent on the users. Some of the other options are list-members, edit and export(to CSV)/import. Hence, these would be easier to build after a basic user class is available. Also maybe you can try making your tool a little more smart? Like lets say I try to create a list abhil...@raj.com and there is no domain raj.com in the database, so instead of just showing error maybe you can ask the user: The domain raj.com does not exist, Do you want to create one? [y/n] Just adding all the options using argparse is really not a very tough job (and with your pace, it is definitely not going to last more than one month ;-). Try to put some more thought to how you can make this tool more intuitive for the end user. What I belive is that deleting a domain should not strightforward, any destructive command should not be. Would it not be nice to prompt the user once before deleting? as in There are 100 lists associated with this domain. Once deleted you cannot undo it, Do you really want to delete x...@yyy.com?[y/n] Or maybe it could schedule a deletion after a pre-defined time with a reasonable default lets say 1 Day? And for an urgency(to delete) there could be --force argument? I roughly went through your code, and I have a few more points: * You should write tests, before writing more code. Infact you should follow TDD (ofcourse if you are comfortable doing it) since the outcome of your commands is less likely to change, even though your code does. * The commit messages should be written in a language that tells a reader What this commit does?. Like Adds documentation file using.txt. Instad of answering What I have done in this commit? Although it is my point of view, AFAIK it is also preferred by many other developers.(See commit messages of barry on lp:mailman) Everything else seems fine. Will apply the necessary changes. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
As discussed, I have completed the r54, that does the following 1. The arguments will be specified as positional arguments wherever necessary and possible. The ideal way to use positional arguments here is if the argument to the command is the name of an instance the scope, use positional args else use optional args E.g, To filter mailing lists based on domains, do mmclient show list --domain domain.org and not mmclient show list domain.org To create a list, do mmclient create list l...@domain.org instead of mmclient create list --list list --domain domain.org 2. Added a no-header option to the detailed listing so that it becomes easier to pip the output. I will be making the following changes for r55 1.Delete Quite a straightforward one. delete list l...@domain.org delete domain domain.org 2. Begin the third `scope` user and add methods like create, delete and list. create user f...@bar.com --password PASS --name NAME list user [--verbose] [--no-header] The user class would be built and managed in the same way as other classes. r55 would be an easy one. Once the above changes are approved, r55 can be completed in a day. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
Hi, I have pushed the revision 53, that has the following changes. 1. Refactoring as mentioned in the comments by Steve 2. Grouping of options and sub commands using subparsers 3. Changed the format of the command from *mmclient scope action* to *mmclient action scope* 4. Replaced ambiguous action *list* with *show* The change mentioned in point 2 solves many/most of the problems raised during the recent discussions. The options are now paired with their corresponding sub commands. The implications of this change is that the extra options/arguments raise command syntax errors, which were ignored earlier. Further, an great extent of leniency can be allowed in the command format. To be specific, the parser can support the commands *mmclient create list --list list1 --domain domain.org* and *mmclient set --key foo --value bar* at the same time. Note that the second command has not specified a scope.(PS: scope as in list, domain, user etc, and not site-wide, domain etc). The change also prevents argparse from generating a dictionary with all possible options (which may be huge). The agreed change to add a positional argument for the *name* (commands of the form *mmclient create list l...@domain.org*) has been postponed to the next revision, as this revision mostly contains code refactoring. http://bazaar.launchpad.net/~rajeevs1992/mailman.client/mailmancli/revision/53 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
On Tuesday 13 May 2014 07:12 PM, Barry Warsaw wrote: On May 13, 2014, at 03:27 PM, Rajeev S wrote: Would --list be implied by seeing a `--listname=l...@example.com`? E.g. would this be just as useful, and a little shorter: mmclient show --listname=l...@example.com --domain=example.org ? In the command *mmclient scope action* , the scope denotes the class name and the action denotes the class method to be invoked. The following format suggested by you, mmclient show --listname=l...@example.com --domain=example.org From the developer point of view, its difficult to map an action to a class by using this format. For eg, the above command can be associated with the class domain or list, as the order of the arguments is insignificant. Further, the commands do not offer much advantage to the user in terms of usability. Most of the current (frequent) commands are quite straightforward and similar to the ones to be used in the shell, for eg, *create list l...@domain.org* compared to *create --listname=l...@domain.org*. Some commands like *add-role* are less intuitive in this format,yet provide a tolerable level of understandability. which makes the outcome dependent on the order in which the if-else's are written. This is a serious bug when actions like `delete` are being used. Destructive actions should probably be more constrained in what they allow, so that there's no possibility of ambiguity on either the part of the user or the code. In the face of ambiguity, refuse the temptation to guess. Got a bit confused with the use of *scope* in this context. Anyways, if the scope is not specified, apply the setting on a default *scope*, `default=site-wide` makes sense, while others do not. Hmm. If scope is optional (because it has a default), then it's not a required positional argument, right? So shouldn't a --switch should be used? A switch would work best when the number of possible choices are very few. Here we have the following choices for the scope, site-wide, domain and list. It seems OK to use a switch here. However, using switches limits the extendibility of the scopes. If a new scope is to be added some day (something server-wide?), integrating new switches is not an easy task, when compared to the addition of a new choice for scope in current approach. And as the final word, I am ready to change the command style, mmclient action scope arguments if there is some serious disagreement with it. I just want it to be consistent, easily described, and easily understood by users. If it makes sense for the mmclient CLI to different from the shell-access mailman command, then we at least need to be translatable between the two. The current format of commands,mmclient scope action arguments is directly translatable to the shell. In fact, they are almost similar, except for the `--` in the commands. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
On Monday 12 May 2014 10:15 PM, Stephen J. Turnbull wrote: Barry Warsaw writes: Also as a general rule, I think we want just one level of subcommand, so that `mmclient show --list` would be the template. (That's open to discussion.) I wonder about this in the context of argparse and the command line, because argparse makes a strong distinction (and corresponding associations) between *required positional* arguments and *optional* keyword-like arguments (ie, any argument with leading dashes). Positional arguments *can be made* optional, also be supplied with a default value, in case the argument was not specified. In my opinion, I don't like the `one level of sub command` as neither the user nor the developer is benefited of such a design. The user ends up typing the same strings as before plus an extra `--` followed by the same set of arguments. And from the angle of implementation, each of the *scope* name would require a different optional argument, followed by a set of if-else's to land at the right *scope* to manage. Further there is a possibility of the user specifying multiple scopes, mmclient show --list --listname l...@domain.org --domain which makes the outcome dependent on the order in which the if-else's are written. This is a serious bug when actions like `delete` are being used. In the model Rajeev has shown so far, the scope argument (list, domain, user) hasn't been optional. I assumed this model was OK since I had received no comments against that part, since the beginning. I strongly believe that it is quite effective to mention the scope this way. mmclient set --key name --value value This seems unnecessarily verbose on the one hand, and to not actually correspond to an actual use case, on the other: there's no scope mentioned. I feel the scope should be mandatory, even if it's sitewide: mmclient set --site-wide --key CAN_PERSONALIZE --value No mmclient set --domain=python.org --key CAN_PERSONALIZE --value Yes (after the first one, the second would be an error, I guess, but in other cases a site-wide setting would be interpreted as a default). Got a bit confused with the use of *scope* in this context. Anyways, if the scope is not specified, apply the setting on a default *scope*, `default=site-wide` makes sense, while others do not. I guess this horse has already bolted the barn, but I wonder about a syntax like mmclient set --site-wide --key PERSONALIZE --value Permitted mmclient set --domain=python.org --key PERSONALIZE --value Permitted mmclient set --list=mailman-us...@python.org --key PERSONALIZE --value No for resource constraining settings. (Permitted could probably be an alias for False.) Sorry about the horse :). As I said, I assumed it was OK, and It was a mistake from my part not to discuss the command syntax before working on it. Also, the above is still possible with the current version. The *scope* positional argument can be made to default to a *scope* that has no solid structure, `settings` for example. More generally, it could be defaulted to a `general` scope, managed by a `General` class, that inherits from multiple classes like `Settings`, `Backup/restore` etc. And as the final word, I am ready to change the command style, mmclient action scope arguments if there is some serious disagreement with it. Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
On Monday 12 May 2014 09:12 PM, Barry Warsaw wrote: A better name might be `show` since the term list is so overloaded in this context. Here's it's being used as a verb and a noun to refer to different concepts, and I think that's confusing. Yes, its confusing. In fact, I was looking for a replacement for that. Thanks. Also as a general rule, I think we want just one level of subcommand, so that `mmclient show --list` would be the template. (That's open to discussion.) ... Yuck. Sorry but I'd like to discourage the use of made up or concatenated words. It's okay for some options to be multi-word separated by dashes, e.g. --affect-bar or --change-foo. I don't have a good alternative atm. Will do. E.g. mmclient set --key name --value value I have answered this part and the `one level subcommand` part in the reply to Steve's mail. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
Hi, I have elaborated the implementation and the motivations behind the current approach in the following blog post, in case it might help reviewing the code better. http://myfossblog.blogspot.in/2014/05/lets-talk-over-cup-of-code.html ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
Hi, I have added two more methods, *create domain* and *list mailing lists*. The listing feature is performed using the `tabulate` module, which I have added to the install_requires. Also, the usage of the CLI is explained in the cli/docs/using.txt. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Fri, May 2, 2014 at 9:06 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi, I have added the licensing blocks to the files and pushed the code. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Fri, May 2, 2014 at 7:13 AM, Barry Warsaw ba...@list.org wrote: On May 02, 2014, at 06:36 AM, Rajeev S wrote: 3.The code has been verified with pep8 *and* flake8 tools. It also passes most of the guidelines mentioned in Barry's styleguide. Some of the guidelines are yet to be met, like the licensing block and stuff like __all__. Also the ^L at major sections are also not added.(Is it still necessary?) Files should definitely all have licensing blocks. ^Ls are not required. I find them useful for Emacs navigation, but I understand they may be distracting for other folks in other editors. I really need to update the style guide for Python 3 and not-quite-Python-3-yet. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/rajeevs1992%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
Stephen J. Turnbull wrote: Ah, OK, I see what you're getting at now. I think this is out of scope for the CLI project, although it's possible that providing some kind of scriptable interface (even a simple way to store a sequence of commands acting on the current list should suffice, where current list is a concept his proposal already includes) would allow it to be implemented relatively easily. I'll discuss that with Rajeev later. Still, I would expect that the right place to expose a list style capability is in Postorius. Most list admins are not even going to have access to the CLI, most likely, because we have *no* security model for it yet, except shell access to the list host. The CLI is going to be a power user's and sysadmin feature more than the way to manage lists for most people, AIUI. (Again, this is negotiable with the student.) Adding a list style attribute would be simple to implement, as Barry had mentioned. Also, list styles probably should be stored in the Mailman core so they can be accessed from any client (which is what takes it right out of the scope of this GSoC IMO, although that's negotiable, again according to Rajeev's interest). I have not concentrated much on the mailman core as it has least to do with my proposal. All I have done with the mailman core is to go through the table schema as it might be useful for the command shell. However, I will give it a try. HTH, Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Mailman CLI Project
Hi, I have added the licensing blocks to the files and pushed the code. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Fri, May 2, 2014 at 7:13 AM, Barry Warsaw ba...@list.org wrote: On May 02, 2014, at 06:36 AM, Rajeev S wrote: 3.The code has been verified with pep8 *and* flake8 tools. It also passes most of the guidelines mentioned in Barry's styleguide. Some of the guidelines are yet to be met, like the licensing block and stuff like __all__. Also the ^L at major sections are also not added.(Is it still necessary?) Files should definitely all have licensing blocks. ^Ls are not required. I find them useful for Emacs navigation, but I understand they may be distracting for other folks in other editors. I really need to update the style guide for Python 3 and not-quite-Python-3-yet. -Barry ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/rajeevs1992%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [GSoC 2014] Mailman CLI Project
Hi, I will be using the following branch for the Mailman CLI project *https://code.launchpad.net/~rajeevs1992/mailman.client/mailmancli https://code.launchpad.net/~rajeevs1992/mailman.client/mailmancli* I have created and committed the basic structure of the project in the branch.Also, as the first step I have implemented the create list functionality for the command line tools. A few snapshots: 1.As discussed in stage of proposal review, the command mmclient (currently script) triggers the shell if no argument is specified and performs the action when an argument is supplied. 2.The argparse module has been used for parsing arguments. Shell is built using Cmd module, currently no functionality. 3.The code has been verified with pep8 *and* flake8 tools. It also passes most of the guidelines mentioned in Barry's styleguide. Some of the guidelines are yet to be met, like the licensing block and stuff like __all__. Also the ^L at major sections are also not added.(Is it still necessary?) 4.The code rests in mailman.client/src/mailmanclient/cli I guess it would be easier to discuss the design and architecture based on this. *Regards,* *Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Please don't top-post. It's very helpful to readers to keep the subthreads about particular issues separate, while at the same time bundling them together for ease of mail-handling. Why not? The CLI tools will have access to the user database, so in theory you could authenticate. In *practice*, this may be outside of the scope of your project because there's no provision for authentication in the current RESTful interface; you end up restricting to connections from localhost. I have given this some thought and yes, you can authenticate and authorize in both shell and tools interface. Authn/authz in shell is quite straightforward as Abhilash mentioned and with the CLI tools, it can be achieved, in a not so easy way. SSH keys can be used to register your shell with the server which can be used as a token for authn/authz for the shell user, just like the interface provided by cloud services like heroku.You do a *heroku login *from your shell and you can run commands on the remote server of your application from your shell.This would be an interesting project and would hugely benefit usability of the current project. But by the same token, past projects have decided to connect to Postorius rather than Mailman itself precisely because Postorious *does* maintain roles and credentials for users. Again, probably beyond the scope of your project, but for precisely this reason it has been proposed a few times that the authn/authz part of Postorius be broken out into a separate module. I agree with your logic here. But I find the text very difficult to read. There should be at least one space after a sentence-ending period (Yes.Users looks like a class attribute!) And I have no idea what the semantics of * is intended to be. That seems like a funny GMail bug. All I did was to reorder the terms of the phrase which was in boldface, using cut and paste. Anyway, I will remember not to do this again. Despite the current thread on python-devwink target=Barry/, I strongly recommend the pep8.py tool (available on PyPI as well as upstream: https://github.com/jcrocholl/pep8/). pyflakes, pylint, and pychecker are also good tools, but their orientation is a bit different, and you may or may not find them useful (and in particular you may find after a while that you *never* get warnings from them). I have used pychecker before. Barry's guidehttp://barry.warsaw.us/software/STYLEGUIDE.txt followed by a PEP8 verifier would do good. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Hi Abhilash, I did not quite get the user role part.A command line utility runs on the server on which a software instance runs, just like a MySQL command line utility.You will need physical access to the system or atleast the shell.I believe you cannot expect every moderator of the list to have that kind of access. From my point of view, the tool will be used by the list owner or the server admin, just like the MySQL shell,which can be used only if you have access to system shell.However, User/Role management can be imposed by including a login for the shell,if necessary.Again,that's not possible for the command tools. And Yes.Users will be a part of this. I prefer to build the other two first.Many methods that can come under User class is better suited under the other two.For eg, for adding a moderator to the list, you can do, *list --addmoderator user_id , *which should be under the List class*. *But the same from user point of view, would be a complicated and less intuitive command, *user **user_id **--addmoderator **--list list_id *. So, after the list and domain functions are built, It will be more clear what the user class must do. About optparse, I actually meant argparse,sorry about that :). And thanks for the style guide tip. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Sat, Apr 26, 2014 at 10:42 AM, Abhilash Raj raj.abhila...@gmail.comwrote: On Fri, Apr 25, 2014 at 6:14 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi Stephen, The CLI project would be a sub module for the mailman.client project. Since bzr does not have the submodule feature, I must be doing it either by using a new repository or as a new branch to mailman.client .The latter would be better as it would be easier to integrate the code into the mailman.client project when this project is completed. Why do you want it to be a submodule in the first place? If you want to extend mailman.client they why not simply branch it? Now about the implementation part.As described in the project timeline, the first phase would be to build the command tools. I would be building two classes List and Domain, and identify the various methods that are to be given to them. Many of the methods are identified in my GSoC proposal. The command parsing would be handled by the python Optparse library. Are users not going to be a part of this? Or you have thought of something else for managing users? Also in your proposal I don't find any mention of user roles. How will you manage user roles? Is the command line tool that you want to build will only be accessible by the supersuser/admin? Or moderators and assigned list owners can also use it to do whatever it does? Also if you allow moderators and owners then you probably have to think of something about permissions to restrict everyone to use the features only specific to there role. From my point of view this project would (someday) be an command line alternative to postorius for admin roles. Not that you have to do everything in this summer, but it should be kept in mind while you work on it. Also may I suggest you to use argparse instead of optparse -- it is now depricated since py2.7. I would like to start building the Version 0, but not to throw away, but will be refining it further as per the feedback. If all this is OK I would start building the version and push it to the mailman.client project. You probably should figure out everything before you jump on to coding. The time till 19th May is allotted for community bonding and there is a reason for that. Try to understand how new features are discussed in here(mailman community) before becoming python statements. I don't know if you already have, but try to read the source code and understand the coding style Barry prefers. There is a style guide for mailman, find it out. And forget about the git vs bzr part. I am OK with using bzr :). Great. thanks, Abhilash Raj ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Hi Stephen, The CLI project would be a sub module for the mailman.client project. Since bzr does not have the submodule feature, I must be doing it either by using a new repository or as a new branch to mailman.client .The latter would be better as it would be easier to integrate the code into the mailman.client project when this project is completed. Now about the implementation part.As described in the project timeline, the first phase would be to build the command tools. I would be building two classes List and Domain, and identify the various methods that are to be given to them. Many of the methods are identified in my GSoC proposal. The command parsing would be handled by the python Optparse library. I would like to start building the Version 0, but not to throw away, but will be refining it further as per the feedback. If all this is OK I would start building the version and push it to the mailman.client project. And forget about the git vs bzr part. I am OK with using bzr :). *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Tue, Apr 22, 2014 at 9:01 PM, Stephen J. Turnbull step...@xemacs.orgwrote: Just to follow up quickly (I've got problems I need to deal with elsewhere over the next couple days). Abhilash Raj writes: Hey, thanks for jumping in, maxking! Hi Rajeev, Congratulations! We look forward to a great summer with you. Definitely! I would like to thank the Mailman community and mentors for their extensive support during my application process, You're very welcome. Also I have a few questions as part of the community bonding process. 1.Is the project to be developed as an independent project or as a part/branch of the Mailman Core repository That is supposed to be an implementation detail of your proposal. What do you think would be the best? I agree with Abhilash. You make a proposal, we'll criticize it (contructively; criticism is not necessarily negative, just as with literary critics we may give a positive review -- you should know when you're doing things right). 2.If it is an Independent project, Is it OK to use the git+gitorious/savannah or should I stick to bzr+launchpad? I have used git extensively,naturally more comfortable with git. However, I can pick up bzr if necessary. Even if it is an independent project we strongly encourage you to use bzr, as integration and code review might become a problem in later stages of your project( I am speaking from personal experience). Learning bzr and launchpad is not at all difficult if you know git. The CLI won't be *that* independent. It really needs to be on Launchpad. Note: It may be possible to use git-bzr to fetch and push from Launchpad. 3.Is it necessary for me to hangout in the IRC?If yes, when? It is not *necessary* for you to hangout on IRC. You just need to keep your mentors updated about what are you doing all the time. If you prefer email, I don't think that would be a problem. Your only responsibility is to deliver the project you proposed on time. It's generally a good idea to have interaction (brainstorming) when working on design. I can generally be available on IRC from about 01:00 UTC to 15:00 UTC. As Abhilash knows :-) I can often be convinced to stay around until about 17:00 UTC. yaseppochi @ freenode 4.Can I start coding right away? You can, but first be sure you know what you want to code. Your proposal does have a detailed description on working of the tool, however there is little mention about the details of implementation and design. It would be best if you first consult with your mentors and decide on something so that you don't waste time writing code that is not needed. Read Fred Brooks' /The Mythical Man-Month/, especially the essay Build One to Throw Away. Then think about whether you really believe him. :-) Regards and looking forward to working with you! Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Hi, My proposal has been successfully accepted into the GSoC 2014 program.I would like to thank the Mailman community and mentors for their extensive support during my application process,especially Mr. Stephen Turnbull. Also I have a few questions as part of the community bonding process. 1.Is the project to be developed as an independent project or as a part/branch of the Mailman Core repository 2.If it is an Independent project, Is it OK to use the git+gitorious/savannah or should I stick to bzr+launchpad? I have used git extensively,naturally more comfortable with git.However, I can pick up bzr if necessary. 3.Is it necessary for me to hangout in the IRC?If yes, when? 4.Can I start coding right away? Thank you once again! *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Thu, Mar 20, 2014 at 6:50 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi, Made a minor edit upon Meflin's comment, asking to change project title. http://myfossblog.blogspot.in/2014/03/yet-another-change.html *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Fri, Mar 14, 2014 at 3:50 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi, I have submitted a proposal for the Mailman CLI project through melange.You can find it here https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/rajeevs1992/5629499534213120 (Organisation view only) I have gone through the suggestions by Stephen as comments to the proposal and revised the proposal accordingly. http://myfossblog.blogspot.in/2014/03/gsoc-proposal-to-gnu-mailman.html *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Hi Abhilash, Thank you for the reply. I will post a write up describing the implementation details of the project.All other issues stand resolved.I will be using bzr+launchpad,and I prefer mail to IRC. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Tue, Apr 22, 2014 at 7:42 PM, Abhilash Raj raj.abhila...@gmail.comwrote: Hi Rajeev, Congratulations! We look forward to a great summer with you. On Tue, Apr 22, 2014 at 3:47 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi, My proposal has been successfully accepted into the GSoC 2014 program.I would like to thank the Mailman community and mentors for their extensive support during my application process,especially Mr. Stephen Turnbull. Also I have a few questions as part of the community bonding process. 1.Is the project to be developed as an independent project or as a part/branch of the Mailman Core repository That is supposed to be an implementation detail of your proposal. What do you think would be the best? 2.If it is an Independent project, Is it OK to use the git+gitorious/savannah or should I stick to bzr+launchpad? I have used git extensively,naturally more comfortable with git.However, I can pick up bzr if necessary. Even if it is an independent project we strongly encourage you to use bzr, as integration and code review might become a problem in later stages of your project( I am speaking from personal experience). Learning bzr and launchpad is not at all difficult if you know git. 3.Is it necessary for me to hangout in the IRC?If yes, when? It is not *necessary* for you to hangout on IRC. You just need to keep your mentors updated about what are you doing all the time. If you prefer email, I don't think that would be a problem. Your only responsibility is to deliver the project you proposed on time. 4.Can I start coding right away? You can, but first be sure you know what you want to code. Your proposal does have a detailed description on working of the tool, however there is little mention about the details of implementation and design. It would be best if you first consult with your mentors and decide on something so that you don't waste time writing code that is not needed. Thank you once again! *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Thu, Mar 20, 2014 at 6:50 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi, Made a minor edit upon Meflin's comment, asking to change project title. http://myfossblog.blogspot.in/2014/03/yet-another-change.html *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Fri, Mar 14, 2014 at 3:50 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi, I have submitted a proposal for the Mailman CLI project through melange.You can find it here https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/rajeevs1992/5629499534213120 (Organisation view only) I have gone through the suggestions by Stephen as comments to the proposal and revised the proposal accordingly. http://myfossblog.blogspot.in/2014/03/gsoc-proposal-to-gnu-mailman.html *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://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 https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Hi, Made a minor edit upon Meflin's comment, asking to change project title. http://myfossblog.blogspot.in/2014/03/yet-another-change.html *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Fri, Mar 14, 2014 at 3:50 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi, I have submitted a proposal for the Mailman CLI project through melange.You can find it here https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/rajeevs1992/5629499534213120 (Organisation view only) I have gone through the suggestions by Stephen as comments to the proposal and revised the proposal accordingly. http://myfossblog.blogspot.in/2014/03/gsoc-proposal-to-gnu-mailman.html *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Hi, I have submitted a proposal for the Mailman CLI project through melange.You can find it here https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/rajeevs1992/5629499534213120 (Organisation view only) I have gone through the suggestions by Stephen as comments to the proposal and revised the proposal accordingly. http://myfossblog.blogspot.in/2014/03/gsoc-proposal-to-gnu-mailman.html *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface
Hi Bhargav, You will be asked whether to *add a superuser* during *syncdb*. If you answered no to that, do *python manage.py createsuperuser * and use that username and password to login. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Wed, Mar 5, 2014 at 8:05 PM, Bhargav Golla bgo...@g.clemson.edu wrote: Hi Abhilash If you mean the last step of installation where we do cd postorius_standalone;python manage.py syncdb, I wasn't asked for any username/password. I checked the settings.py and it doesn't have any specific default username/password. And the http://localhost:8001/3.0 worked for me. On Wed, Mar 5, 2014 at 9:22 AM, Abhilash Raj raj.abhila...@gmail.com wrote: Hi Bhargav, On Wednesday 05 March 2014 07:36 PM, Bhargav Golla wrote: Thanks for that change Rajeev. I was able to get the Web UI up and running. I was trying to find out the default Username and password for this but was unable to. When I was exploring docs in mailman.client and some config files in mailman, I found that the default username and password for admin is restadmin and restpass. Tried that and was out of luck there too. Could you help me with the default username and password details? While setting up Postorius(the web UI) when you do 'python manage.py syncdb' for the first time, it asks you to create admin. You can log in using those credentials. 'restadmin' and 'restpass' are the credentials for the mailman rest server. Also, there is a using.txt doc in mailman.client which says we can make the REST requests by connecting to http://localhost:9001/3.0 using username and password. Should the URL be http://localhost:9000/3.0 for this example or would it be any different? AFAIK it is 'http://localhost:8001/3.0'. (Try it once. If I am wrong please someone correct me) Thanks On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi Bhargav, Just do *mailman start*, without the bin. I have edited the wiki. *Regards, Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla bgo...@g.clemson.edu wrote: Thanks Barry and Terri for your feedback. I was trying to install Postorius locally and analyze what all would be required in a mobile app for Admin. Doing the same, I have hit a roadblock. I am using the wiki provided here[1]. I tried to install mailman using set up sources part of the wiki. Though python setup.py install executes without any errors, I am unable to see the folder bin/ in the same directory. So, even though I proceed with further setup, I am getting a Mailman REST API not available. Please start mailman core on my localhost:8000 webpage. Could anyone help me here? [1] http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running Thanks On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda te...@toybox.ca wrote: On 2014-02-28, 7:36 AM, Bhargav Golla wrote: I have a few questions regarding this idea. 1. I intend to develop it on Cordova since it will help in porting the app easily to multiple platforms. Were there any ideas in this directions regarding going native or hybrid? Personally, I'd prefer if we went hybrid and had an html5 webapp that could be used straight over the web for mobile users who don't want to install an app, with Cordova used to build the individual platform apps. I may not be the mentor on this one, though, so I'm happy to defer to whoever the final mentor is on this front. Incidentally, I've been using Intel's XDK for building Cordova apps lately and highly recommend it for quick testing on various platforms and screen sizes. I've found it a very useful tool, and not just because I work for Intel now! 2. Can I assume that all mailing lists built by Mailman support the REST interface? Also, I have tried to see if I can get JSON responses and I am unable to by adding a HTTP Accept Header to take application/json. Am I doing anything wrong or is JSON not implemented? I don't know the answer to this off the top of my head: Barry? 3. As a starter, could I ignore internationalization for GSoC, but implement interface in such a way as to be able to internationalize it easily? We don't expect you to actually translate anything, don't worry. :) But you should definitely build as much as possible so that internationalization will be easy: make sure there's a quick way to get a list of strings that need translation, at least. Some of the strings may be already translated in other components of Mailman, so you may be able to get some translations to use to test
Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface
Hi, You will be asked for the create user prompt only the first time you run syncdb.That's why you don't see it now. Once the DB is created, only new tables, specified via django models, get added to DB during the syncdb. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Wed, Mar 5, 2014 at 8:47 PM, Bhargav Golla bgo...@g.clemson.edu wrote: Hi Rajeev I wasn't asked if I wanted to create a super user when I executed python manage.py syncdb. This was the output I got with syncdb: Creating tables... Installing Custome SQL... Installing indexes... Installed 0 object(s) from 0 fixture(s) I tried python manage.py createsuperuser and was able to login with details I provided there. Thanks for your help. Regards On Wed, Mar 5, 2014 at 10:00 AM, Rajeev S rajeevs1...@gmail.com wrote: Hi Bhargav, You will be asked whether to *add a superuser* during *syncdb*. If you answered no to that, do *python manage.py createsuperuser * and use that username and password to login. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Wed, Mar 5, 2014 at 8:05 PM, Bhargav Golla bgo...@g.clemson.eduwrote: Hi Abhilash If you mean the last step of installation where we do cd postorius_standalone;python manage.py syncdb, I wasn't asked for any username/password. I checked the settings.py and it doesn't have any specific default username/password. And the http://localhost:8001/3.0 worked for me. On Wed, Mar 5, 2014 at 9:22 AM, Abhilash Raj raj.abhila...@gmail.com wrote: Hi Bhargav, On Wednesday 05 March 2014 07:36 PM, Bhargav Golla wrote: Thanks for that change Rajeev. I was able to get the Web UI up and running. I was trying to find out the default Username and password for this but was unable to. When I was exploring docs in mailman.client and some config files in mailman, I found that the default username and password for admin is restadmin and restpass. Tried that and was out of luck there too. Could you help me with the default username and password details? While setting up Postorius(the web UI) when you do 'python manage.py syncdb' for the first time, it asks you to create admin. You can log in using those credentials. 'restadmin' and 'restpass' are the credentials for the mailman rest server. Also, there is a using.txt doc in mailman.client which says we can make the REST requests by connecting to http://localhost:9001/3.0 using username and password. Should the URL be http://localhost:9000/3.0 for this example or would it be any different? AFAIK it is 'http://localhost:8001/3.0'. (Try it once. If I am wrong please someone correct me) Thanks On Mon, Mar 3, 2014 at 1:38 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi Bhargav, Just do *mailman start*, without the bin. I have edited the wiki. *Regards, Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla bgo...@g.clemson.edu wrote: Thanks Barry and Terri for your feedback. I was trying to install Postorius locally and analyze what all would be required in a mobile app for Admin. Doing the same, I have hit a roadblock. I am using the wiki provided here[1]. I tried to install mailman using set up sources part of the wiki. Though python setup.py install executes without any errors, I am unable to see the folder bin/ in the same directory. So, even though I proceed with further setup, I am getting a Mailman REST API not available. Please start mailman core on my localhost:8000 webpage. Could anyone help me here? [1] http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running Thanks On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda te...@toybox.ca wrote: On 2014-02-28, 7:36 AM, Bhargav Golla wrote: I have a few questions regarding this idea. 1. I intend to develop it on Cordova since it will help in porting the app easily to multiple platforms. Were there any ideas in this directions regarding going native or hybrid? Personally, I'd prefer if we went hybrid and had an html5 webapp that could be used straight over the web for mobile users who don't want to install an app, with Cordova used to build the individual platform apps. I may not be the mentor on this one, though, so I'm happy to defer to whoever the final mentor is on this front. Incidentally, I've been using Intel's XDK for building Cordova apps lately and highly recommend it for quick testing on various platforms and screen sizes. I've found it a very useful tool, and not just because I work for Intel now! 2. Can I assume that all mailing lists built by Mailman support the REST
Re: [Mailman-Developers] [GSoC 2014] Command line Client
Thanks Florian. Things are much more clearer now. I have built a basic command line version for the mailman.client, that will currently print the domain list and mailing list lists. This is, as Steve mentioned, like the git interface You can find it here https://github.com/rajeevs1992/mailman-cli/blob/master/client *Usage:* To list the registered domains in your server, do - ./client domain --list To list the registered mailing lists in your server, do - ./client list --list For help with options available, do - ./client -h *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Wed, Mar 5, 2014 at 3:37 PM, Florian Fuchs flo.fu...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2014 10:49 AM, Stephen J. Turnbull wrote: Rajeev S writes: Also, I did not quite get the *coming up with a **great layout * part. Do you mean to build a custom shell for mailman? If yes, what extra functionality should it provide than the standard command line tools? I think that probably is what he means, but I personally don't think that's appropriate. If people want a CLI with layout (which I agree is plausible), what's wrong with Postorius via Lynx? (Florian?) No, that's not what I meant (using the term layout was obviously confusing - sorry for that!). I think we're talking about two possible, but very different concepts of a client here: One is the one-off command (with options) that outputs a result, either on stdout or saved to a file. This could make for an interesting project, but I think then it would really make more sense (like Steve said) to extend the existing `mailman` command instead of writing a new one. The other (and the one I had in mind) is a tool you invoke with a commando which then offers a interface a little different from that of your standard terminal shell (bash or else). Just like you invoke the mysql/sqlite3 client (with a db name or file as option). What I meant by layout is really the question what happens after one starts the tool by typing something like `$ mmclient --list=f...@bar.id` or `$ mmclient --domain=python.org`, not the actual visual representation. Does that make more sense? Florian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTFvdqAAoJEEceGbPdavl76KIIAKLIsZEux/TPCSNV9sEQGJt1 s5gkIT298wZPPQfG+b2kllMO9o6uObQ0K10Ynk4yzLi1YngTyR1kC52Ty6uZ1pws YvD87o7DCeoZWDMss77+zvJkpkG+zFn4Ts3taeWW/9A1N9fJP22izgtm9aki+RLn 8nWn4jfTmnE3TvU8ptr/5uK0LPApfjMZz0mGCc6jgExdsJhVw11LU0Wzoxtw9424 1ygW2zWPcvdHTqykluvf62u24oTna641vNxE60LB9e4SF6LhS0Pi+F/w+m8zjNAT q3xY76yNlhZVI/N2cR4jinuUbagX61DSu7mgC4Kk08oyN6TgkS9kknlYrGupQ3c= =ufWT -END PGP SIGNATURE- ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Command line Client
Hi Florian, I had discussed about the full anonymization project with Stephen and I had found that I had quite misunderstood the use case of that project. So I have decided to go forward with applying for the mailman command line client project. The deliverables of the project would be, at the least, - Command line tools to perform tasks in the mailman client docs - Any Extra useful functionalities that can be identified, such as export, backup - Other Useful tools like backup and restore. - Man Page entries for the new commands Also, I did not quite get the *coming up with a **great layout * part. Do you mean to build a custom shell for mailman? If yes, what extra functionality should it provide than the standard command line tools? *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Mon, Mar 3, 2014 at 4:35 PM, Florian Fuchs flo.fu...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/25/2014 03:17 AM, Rajeev S wrote: Hi, I am Rajeev S , A CSE Undergrad from India. I would like to work with the Command Line client project listed in the GSoC ideas page. I have been working on the Postorious package lately and have managed to make some tweaks in it, like the add users by file upload and an improved email validator. As a part of the project, I would like to build,at the minimum, the functionalities listed at the mailmain.client/src/mailmanclient/docs/using.txt Can the mentor of this project elaborate upon the requirements of the project? I think the functionalities listed in the mailman.client docs are a good orientation point, because those represent almost everything the core REST API currently exposes. It also makes sense to use mailman.client instead of writing new code that handles the HTTP stuff and object binding. I guess the most difficult part of this project is coming up with a great layout, possibly borrowing stuff from other well-known command line clients (mutt, mysql/sqlite3, the ipython shell, lynx etc.). Of course there are bonus points for all kinds of stuff, like exporting data to files/stdout, making the tool extensible etc. But I really think designing the right interface and implementing most or all of what mailman.client can do will take a good amount time. Also I have thought of an approach for the full anonymization project.Is it possible that I can work on both of these as a single project?(I have a feeling that the CLI is a small project, am I right?) You should definitely pick one project and come up with good ideas for that. Cheers Florian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTFGH3AAoJEEceGbPdavl7ZYIH+gJVB27H6G5LXd+0+vytx1gC sZiQCy/vYEr8jtCbe8BdoLvk+jyBNRaUzaxDuL/9Pb3g8HCwuJQ+HzEQm25ewZ0X vlvWZ7dW07sEYr5q7cRatkqO/GQc2n6B6IgGd3oTkihQUO4iZQTu/ddytMghvCP0 MYtuQyuecjZm8JBlCn6AU0KQWxNx/Kt7CsuPfk6FcCOmA15ZEnZ4kxZFY0khVY5a NLetoDDY7fQAf5fFlea8SfIN8PFB1i4qv5DdjDaX17Yg/S+X5S0nZx18uvqX7Up8 RlGLTCSA8s3qsYItaI9NWpXRdo/Z1p8MN/hQOOot85e3SVernKn9oq1TSI/7lww= =pozr -END PGP SIGNATURE- ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/rajeevs1992%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSoC 2014] Cordova/Android App for GNU Mailman Admin Interface
Hi Bhargav, Just do *mailman start*, without the bin. I have edited the wiki. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Mon, Mar 3, 2014 at 10:37 PM, Bhargav Golla bgo...@g.clemson.edu wrote: Thanks Barry and Terri for your feedback. I was trying to install Postorius locally and analyze what all would be required in a mobile app for Admin. Doing the same, I have hit a roadblock. I am using the wiki provided here[1]. I tried to install mailman using set up sources part of the wiki. Though python setup.py install executes without any errors, I am unable to see the folder bin/ in the same directory. So, even though I proceed with further setup, I am getting a Mailman REST API not available. Please start mailman core on my localhost:8000 webpage. Could anyone help me here? [1] http://wiki.list.org/display/DEV/A+5+minute+guide+to+get+the+Mailman+web+UI+running Thanks On Sun, Mar 2, 2014 at 1:18 AM, Terri Oda te...@toybox.ca wrote: On 2014-02-28, 7:36 AM, Bhargav Golla wrote: I have a few questions regarding this idea. 1. I intend to develop it on Cordova since it will help in porting the app easily to multiple platforms. Were there any ideas in this directions regarding going native or hybrid? Personally, I'd prefer if we went hybrid and had an html5 webapp that could be used straight over the web for mobile users who don't want to install an app, with Cordova used to build the individual platform apps. I may not be the mentor on this one, though, so I'm happy to defer to whoever the final mentor is on this front. Incidentally, I've been using Intel's XDK for building Cordova apps lately and highly recommend it for quick testing on various platforms and screen sizes. I've found it a very useful tool, and not just because I work for Intel now! 2. Can I assume that all mailing lists built by Mailman support the REST interface? Also, I have tried to see if I can get JSON responses and I am unable to by adding a HTTP Accept Header to take application/json. Am I doing anything wrong or is JSON not implemented? I don't know the answer to this off the top of my head: Barry? 3. As a starter, could I ignore internationalization for GSoC, but implement interface in such a way as to be able to internationalize it easily? We don't expect you to actually translate anything, don't worry. :) But you should definitely build as much as possible so that internationalization will be easy: make sure there's a quick way to get a list of strings that need translation, at least. Some of the strings may be already translated in other components of Mailman, so you may be able to get some translations to use to test if you have time at the end of the summer for internationalization. Terri -- Bhargav Golla M.S Computer Science Github http://www.github.com/bhargavgolla | LinkedINhttp://www.linkedin.com/in/bhargavgolla | Website http://www.bhargavgolla.com/ ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/rajeevs1992%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] [GSOC 2014]Approach towards the Full anonymization project
Hi, I have written and deployed an App that generates and decodes anonymous emails,as I had mentioned. Find the application here http://anongen.herokuapp.com/ Source here https://github.com/rajeevs1992/anongen *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Tue, Feb 25, 2014 at 8:18 AM, Rajeev S rajeevs1...@gmail.com wrote: Hi, As mentioned, here is my approach towards the full anonymization project. - Introduce a new model EmailMapper with attributes - ForeginKey to Address / User - seed, A 40 bit hash,unique - nuses, number of times this hash is used,max 5 or 10 - The approach is to encrypt the seed nuses times, with encryption algorithms like AES, each time the email ID is displayed. - The email ID is displayed as nusesencrypted seed - The email is decrypted nuses times to find the parent seed and thereby point to the exact email address. - A new seed should be generated for the user after a fixed number of attempts,say 5 or 10,as the repeated encryption routines can slow down the system. The outcomes - Everytime the user sends a message,his from address changes. - At the same time, each of the from addresses point to the same user. - The sender can use any stored address he has,like in the mail contacts,repeatedly, to contact with a user,as it has nuses attached with it. If this approach seems viable or if I am missing something important,please let me know.If this is fine, I would build an app that can demonstrate this functionality, before building my application. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [GSoC 2014] Command line Client
Hi, I am Rajeev S , A CSE Undergrad from India. I would like to work with the Command Line client project listed in the GSoC ideas page. I have been working on the Postorious package lately and have managed to make some tweaks in it, like the add users by file upload and an improved email validator. As a part of the project, I would like to build,at the minimum, the functionalities listed at the mailmain.client/src/mailmanclient/docs/using.txt Can the mentor of this project elaborate upon the requirements of the project? Also I have thought of an approach for the full anonymization project.Is it possible that I can work on both of these as a single project?(I have a feeling that the CLI is a small project, am I right?) *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] [GSOC 2014]Approach towards the Full anonymization project
Hi, As mentioned, here is my approach towards the full anonymization project. - Introduce a new model EmailMapper with attributes - ForeginKey to Address / User - seed, A 40 bit hash,unique - nuses, number of times this hash is used,max 5 or 10 - The approach is to encrypt the seed nuses times, with encryption algorithms like AES, each time the email ID is displayed. - The email ID is displayed as nusesencrypted seed - The email is decrypted nuses times to find the parent seed and thereby point to the exact email address. - A new seed should be generated for the user after a fixed number of attempts,say 5 or 10,as the repeated encryption routines can slow down the system. The outcomes - Everytime the user sends a message,his from address changes. - At the same time, each of the from addresses point to the same user. - The sender can use any stored address he has,like in the mail contacts,repeatedly, to contact with a user,as it has nuses attached with it. If this approach seems viable or if I am missing something important,please let me know.If this is fine, I would build an app that can demonstrate this functionality, before building my application. *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Fwd: Implemented Mass Subscription via file upload
First of all, there is no propose to merge link on my https://code.launchpad.net/~rajeevs1992/mailman-rajeevs1992/trunk page. home.pnghttps://docs.google.com/file/d/0B0oFc02F56UzZUVQQTNRNl9iNnM/edit?usp=drive_web And this is what happens when I propose a merge. proposemerge.pnghttps://docs.google.com/file/d/0B0oFc02F56UzRkU2R0JkeklMbEk/edit?usp=drive_web *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Fwd: Implemented Mass Subscription via file upload
Thanks.Did it anyway,I guess I was biased by the github pull request method, and that did not work with launchpad. Submitted the patch at https://code.launchpad.net/~rajeevs1992/postorius/postorius/+merge/207826 *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Sun, Feb 23, 2014 at 7:55 PM, Mark Sapiro m...@msapiro.net wrote: On 02/23/2014 01:46 AM, Rajeev S wrote: First of all, there is no propose to merge link on my https://code.launchpad.net/~rajeevs1992/mailman-rajeevs1992/trunk page. home.png https://docs.google.com/file/d/0B0oFc02F56UzZUVQQTNRNl9iNnM/edit?usp=drive_web And this is what happens when I propose a merge. proposemerge.png https://docs.google.com/file/d/0B0oFc02F56UzRkU2R0JkeklMbEk/edit?usp=drive_web Sorry, this is beyond my knowledge of launchpad. I'm guessing you may first need to import your branch via https://code.launchpad.net/postorius/+new-import, but I don't really know. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/rajeevs1992%40gmail.com Security Policy: http://wiki.list.org/x/QIA9 ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Implemented Mass Subscription via file upload
Hi, I have implemented a mass subscription via file upload feature for Postorious which can be found here. https://code.launchpad.net/~rajeevs1992/mailman-rajeevs1992/trunk How am I to submit a merge request to the Postorious repository?I tried to propose a merge via the launchpad, but says the branch cannot be merged. What am I doing wrong? *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Implemented Mass Subscription via file upload
Hi Stephen, It was my mistake in *naming* my repository. The https://code.launchpad.net/~rajeevs1992/mailman-rajeevs1992/trunk points to a Postorious repository, which I had downloaded using bzr branch lp:postorius and has following properties push branch: http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/parent branch: http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/ *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Sun, Feb 23, 2014 at 5:52 AM, Stephen J. Turnbull step...@xemacs.orgwrote: Rajeev S writes: I have implemented a mass subscription via file upload feature for Postorious which can be found here. https://code.launchpad.net/~rajeevs1992/mailman-rajeevs1992/trunk How am I to submit a merge request to the Postorious repository?I tried to propose a merge via the launchpad, but says the branch cannot be merged. Postorius is an entirely separate project as far as Launchpad is concerned. Your URL suggests you derived from mailman, in which case Postorius and Mailman share no ancestors and the merge has to fail. If that's not it, I'll try to check the actual code later. :-) Steve ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
