Guillaume MAISON wrote: > 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... ;)
So I guess the Reader/Writer should provide events, something like OnReadStart, OnReadGroup, OnReadAccount.. right? --- Arno Garrels [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- 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
