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
- 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... ;)


Best regards,


83, Cours Victor Hugo
47000 AGEN
Tél : 05 53 87 91 48 - Fax : 05 53 68 73 50
e-mail : [EMAIL PROTECTED] - Web :

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to