You don't need to put me in the addressee list if you Cc mailman-developers.
Rajeev S writes:
As this is a command shell, I wish to give it a SQL like feel.
I don't understand why you want it to feel like SQL. SQL is hardly something I would expect typical list admins to know about. Choice of some of the operators might be inspired by SQL's more-or-less natural language style.
For example,
show users where display_name = 'foo' and subscribed_list_ids contains = 'list@domain.org <mailto:%27list@domain.org>'
Given that we use objects, I somewhat prefer
show users with display_name = 'foo' and subscribed_lists containing 'list.domain.org' or 'list.domain.net'
Or somewhat contorted grammar:
show users with 'foo' as display_name and 'list.domain.org' or 'list.domain.net' in subscribed_lists
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.
I think this is a distinction without a difference as the REST API is usually disabled for remote clients as well.
By using the second approach, the performance is bad, as it requires a normal python
forloop that compares the the results one by one.
Extend the REST API if performance bothers you. (FVO "you" that include future GSoC students and users.) I don't think performance should be a consideration here. Focus on functionality.
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?
I think it should support simple filtering at least.