On Jun 28, 2014, at 10:55 PM, Rajeev S wrote:
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.
Not only that, but there no backward compatibility guarantees about the database schema. The only guarantee is that there will be some automated scripts to do schema migration if it does change.
By using the second approach, the performance is bad, as it requires a normal python
forloop 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.)
Correct, and the core's REST server should never be exposed to the internet. That's the purpose of the REST proxy layer, probably best provided by Postorius, which mediates access to the REST API via an authorization layer.
However, it's entirely feasible that additional REST APIs be built that can provide more advanced access to the data model, such as filtering. Membership search and rosters already provide some functionality like this.
Cheers, -Barry