@David pools are not name-based, but currently there's validation during creation (both via Web UI and REST-like API) so that one cannot create a pool with the same name. It would be confusing for the user, but if this validation is removed, it would be possible to have pools with the same name.
@Xuefeng Instead of having two fields (respectively two database columns)- one to indicate read/write/admin permission and one for disabled/enabled, you could have one field (and one database column) with read/write/admin and *no* permission. This way we avoid the situation when there's e.g. admin permission set, but disabled turned on. You not only must never forget to check both for permission *and* validity, but also find all existing queries in the code and check if they include validity checks. Furthermore, you avoid some tricky issues. How do you find all users with admin privileges? You find privileges which have value Admin and validity is set to true. What about the ones with non-admin privileges? Ones with privileges which either don't have value Admin or ones for which validity is false? Wrong! With so many checks it's easy to forget that users with no privilege are effectively the same as ones which have validity set to false. And for issues like ESME-66 you have to do this same check twice- once for the current user, and once for all other users. Seems to me it's complicated enough even without multiple states that mean the same thing. Vassil
