Arno Garrels a écrit : > I ment I will remove the XML support (probably). > > The component is designed as an 'in memory' account/user database capable > to authenticate users and to store the account data (actually to binary file, > or to an XML file optionaly). I need such a simple component for a service > application that runs a TWSocketServer. The server needs to load user account > data on service start. When a client wants to edit users the server sends > entire > data to the client, after editing client sends data back and server saves > data to disc locally.
Considering what you're doing, i would suggest to create your 'in memory' user accounts manager, with no mean to store/read it from anywhere. Then, after you have designed the manager (add, delete, find, exchange, etc) i would suggest to create one or two more classes : - a Reader class - a Writer class or - a Reader/writer class In fact, i wouldn't make a specific reader/writer class but more a generic one. Then if you want a specific writer or reader, you inherit from this generic class, implementing your own function for each storage support (which can be socket implemented to communicate with a specific server, or INI file based, or DBMS based or Whatever based). In fact, the pattern would be to have your accounts manager ignoring everything on how to store itself and having some classes that "connect" to it, knowing how to handle it to store and/or retrieve its data. not sure to have been clear enough, but... ;) HTH, Best regards, -- Guillaume MAISON - [EMAIL PROTECTED] 83, Cours Victor Hugo 47000 AGEN Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50 e-mail : [EMAIL PROTECTED] - Web : http://nauteus.com -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be