现在网上开放源代码的程序越来越多了，
好处是可以很省事的拿来给自己用，
但是在使用过程中，也发现了一个问题，就是如何维护各个不同系统的会员数据。
下面先列出几个问题：
1. 用户数据也无爱乎增删改查；
2. 使用何种方式整合会员系统（在下面会列出我想到的几种方式）；
3. 注册时候如何统一会员资料的规则（包括注册，修改的规则，例如用户名的最大和最小长度等）；
4. 由第3个问题衍生出来的，会员修改的时候如何统一修改资料的规则；
5. 用户忘记密码时使用何种方式来恢复密码；
6. 目前现实的一个问题，已经有一些源代码系统使用email地址来进行注册了，这样，如何来整合使用email地址与用户名注册的会员系统；
7. 如何实现一些会员权限方面的东西（比如，我在论坛里面定义了一个不用暂时不可以登陆，怎么在自己的member sytem体现出来，又或者，在论坛定义了一个管理员，如何让他也成为其他的管理员？这个感觉有些复杂，可以先不予考虑）；
8. 也是最主要的，如何保证各个程序的会员系统的数据同步。
解决方案（指各个程序系统使用同一种程序语言开发）：
分为两大类：一种是每个源程序都有自己的会员数据库，然后member system也有自己的会员数据库，会员操作的时候都以member system为主，其他的只是单纯的与主数据库进行同步；另外一种是以其中一种源代码程序的会员数据库为主，其他的源代码程序为辅，这样就不需要有自己的 member system数据库了。
下面就这两大类分别讨论：
以下称member system有自己的用户数据库为：a-ms；
member system没有自己的用户数据库为b-ms。
一. 两种方式的优缺点的比较：
a-ms：相对于b-ms来说，a-ms不依赖于任何一套程序，即使我不想用一套程序或者换掉了，但是a-ms还是维护着自己的用户数据，只不过操作的时候不向废除的系统发送请求罢了，灵活性强。
b-ms：从其中选择一套成熟的程序的会员系统部分作为member system，可以节省2次开发的时间，同时这样的缺点也就暴露出来了，当这套程序更新的时候，可能还要把修改过的会员部分的代码再重新修改一次，依赖性强。
目前对比方面就想到这么多，个人还是推崇a-ms方式，感觉灵活性，可扩展性，独立性都比较好。
针对于a-ms的几种具体的解决方法：
1. 查看各个程序的会员系统部分，在member system中分别开发属于各个系统的代码，通过这里来模拟进行member system进行各种操作。但是这种方法很差，开发周期长，效率低，并且兼容性差，如果哪天某个系统升级，可能就要修改相应的代码；
2. 针对于修改第一种的缺点，可以这样，会员的操作提交到member system后，以curl方式来隐含的调用各个系统的相应部分，例如，新注册用户的信息提交过来后，我分别隐含的向各个程序的register程序来告 诉它们，有新用户注册了，请执行相应的操作。这种方法的缺点在于，我要附加一个值隐含的提交给各个程序，要让他们知道是member system进行提交的，否则不予操作。针对于方法一没有解决的问题在于：兼容性虽然比第一种好些，但是还有欠缺，而且这种方法有一个致命的弱点：就是比 如curl方式隐含的调用login部分的程序，没有办法在这个时候写入cookie或者session，所以还要提炼出来cookie或者 session部分进行重写；
3. 针对于以上两种方法，这种方法显然要好些，我的想法是尽可能少的修改源程序文件来实现尽可能灵活的性能，可以自己封装函数，把需要进行操作程序的部分封装 成一个接口，然后这个接口再去调用各个程序相应的接口。这样即使程序升级了，也还是不用修改任何文件的，除非相关的函数调用升级之后做了变化。
针对于b-ms的解决方法：
感觉其实和a-ms的解决方法大同小异，只不过没有自己的用户数据库罢了。
综上所述，我会按照第3种方法来实现的，第一个实现的项目就是我,anakin和bluetent的x3zone::未知立方。
如果朋友们看到有什么不同的想法或者建议，欢迎给我留言一起交流讨论
