Re: [twsocket] UserManager component

2005-12-04 Thread Francois PIETTE
 To store or send component data I use XML format.

Why not using a simple INI file for storage ?
For large data, it can simply be mapped into a SQL table.
--
[EMAIL PROTECTED]
http://www.overbyte.be


- Original Message - 
From: Arno Garrels [EMAIL PROTECTED]
To: ICS support mailing twsocket@elists.org
Sent: Monday, November 28, 2005 9:21 AM
Subject: [twsocket] UserManager component


 Hello,
 
 I'm actually writing a simple user manager component that I would like 
 to contribute to ICS. The component makes use of classes 
 TCollection/TCollectionItem to realize a tree-structure. A user group
 contains accounts, accounts may have parameters.
 To store or send component data I use XML format.
 XML-text is written without the help of a third party component however
 for parsing I use Stefan Heymann's TXmlScanner/TXmlParser
 http://www.destructor.de. It appears to be the freeware solution with
 less overhead. Should I better avoid use of XML and/or third party
 components? Are there alternatives? 
 
 ---
 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
-- 
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


Re: [twsocket] UserManager component

2005-12-04 Thread Francois PIETTE
 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).

Then you can simply create a component containing the informations, have a 
collection of such component and simply stream the collection out to a data 
file. Later you can simply read it back from the file. This is easily 
accomplished using built-in component stream functions. You can find an 
example in WebSession.pas file included with MidWare. See SaveToStream and 
LoadFromStream methods.

--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be



-- 
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


Re: [twsocket] UserManager component

2005-12-04 Thread Francois PIETTE
 To store or send component data I use XML format.

 Why not using a simple INI file for storage ?
 For large data, it can simply be mapped into a SQL table.

 Current state is..
 A base component w/o any storage methods.
From that base I derived two more components,
 one that writes binary to a stream/file and one
 that uses XML (conditional compilation).
 Isn't a tree-structure hard to write to an
 INI file? Actually a user group as well as a user
 may have arbitrary parameters which are derived
 TCollection items as well (properties Name: string
 DataType: Enum; Value: string).

If you need concurrent process reading/writing the tree stored in INI file, 
then yes it is not so easy. But it is very easy for just write the tree to 
the INI file and reload it later. You can simply traverse the tree, 
expanding each node until their leaf and write everything in a single 
section in the INI file. The keys in the section coudl simple be the path in 
the tree. Reloading is also very simple. The keys would looks like the 
output of a dir /b/s and the values associated with the key would be the 
data stored as a string.

 Actually I'm busy with ICS-SSL so I had no time to
 continue the usermanager.

Perfect. ICS-SSL has higher priority of course.

--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be


-- 
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


Re: [twsocket] UserManager component

2005-12-03 Thread Maurizio Lotauro
On 02-Dec-05 11:16:33 Arno Garrels wrote:

Maurizio Lotauro wrote:
 On 30-Nov-05 08:19:53 Arno Garrels wrote:

 Maurizio Lotauro wrote:

 [...]

 Will they contains passwords?

 Yes, with an option to save the MD5-hash only.

 What is the purpose of the component?
 The target is server only or client too?

I made it to manage user accounts no matter whether
the application is client or server.

But for client you can't store the password hashed. Or you are using
only your server that will accept the pwd in MD5?


Bye, Maurizio.

-- 
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


Re: [twsocket] UserManager component

2005-12-03 Thread Arno Garrels
Maurizio Lotauro wrote:
 On 02-Dec-05 11:16:33 Arno Garrels wrote:
 
 Maurizio Lotauro wrote:
 On 30-Nov-05 08:19:53 Arno Garrels wrote:
 
 Maurizio Lotauro wrote:
 
 [...]
 
 Will they contains passwords?
 
 Yes, with an option to save the MD5-hash only.
 
 What is the purpose of the component?
 The target is server only or client too?
 
 I made it to manage user accounts no matter whether
 the application is client or server.
 
 But for client you can't store the password hashed. 

Correct, that's why it's optional. 

 Or you are using
 only your server that will accept the pwd in MD5?

The server accepts the plain text password, builds the
MD5 hash (optional) and compares the value with stored
user password, very simple, nothing for the hall
of fame ;-)


---
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


Re: [twsocket] UserManager component

2005-12-02 Thread Arno Garrels
Maurizio Lotauro wrote:
 On 30-Nov-05 08:19:53 Arno Garrels wrote:
 
 Maurizio Lotauro wrote:
 
 [...]
 
 Will they contains passwords?
 
 Yes, with an option to save the MD5-hash only.
 
 What is the purpose of the component?
 The target is server only or client too?

I made it to manage user accounts no matter whether
the application is client or server.

 
 [...]
 
 Are there alternatives?
 
 Why don't use the streaming capabilities of components?
 
 The XML stuff is a hell. The only advantage of XML is that it can
 be stored in a human readable form, every thing else is a pain.
 
 The content of the dfm are usually human readable too.
 I think that XML is useful only when you need to exchange data with
 some others, in all other case it add only an overhead.
 
 I think I'll kick it out again.
 
 I didn't catch what you mean.

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.  

---
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html

 
 Bye, Maurizio.
-- 
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


Re: [twsocket] UserManager component

2005-12-02 Thread Guillaume MAISON
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


Re: [twsocket] UserManager component

2005-12-02 Thread Arno Garrels
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


Re: [twsocket] UserManager component

2005-12-02 Thread Guillaume MAISON
Arno Garrels a écrit :
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? 

Yes...

The idea would be to create methods and events which are mandatory for 
such readers/writers. After a quick thought i would suggest :

constructor .Create(UserAccountCollection);
method .Write;
   Event .OnBeginWrite(Self);
   Loop
 Event .OnWriteItem(Self, CollectionItem);
   Event .OnEndWrite(Self);

For Read, the problem is that when reading, you cannot know in advance 
what/how you are reading (hence there can't be any ReadItem), so i would 
suggest :

method .Read;
   Event .OnBeginRead(Self);
   Event .OnRead(Self);

method .EndRead;
   Event .OnEndRead(Self);

i would even suggest that the OnEndRead event is triggered whenever the 
developper uses the EndRead method (like the Finish method used in 
Midware ServerObjects). it would permit to use some async socket within 
the OnRead Event...

HTH,

-- 

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


Re: [twsocket] UserManager component

2005-12-01 Thread Maurizio Lotauro
On 30-Nov-05 08:19:53 Arno Garrels wrote:

Maurizio Lotauro wrote:

[...]

 Will they contains passwords?

Yes, with an option to save the MD5-hash only.

What is the purpose of the component?
The target is server only or client too?

[...]

 Are there alternatives?

 Why don't use the streaming capabilities of components?

The XML stuff is a hell. The only advantage of XML is that it can
be stored in a human readable form, every thing else is a pain.

The content of the dfm are usually human readable too.
I think that XML is useful only when you need to exchange data with
some others, in all other case it add only an overhead.

I think I'll kick it out again.

I didn't catch what you mean.


Bye, Maurizio.

-- 
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


Re: [twsocket] UserManager component

2005-11-29 Thread Maurizio Lotauro
On 28-Nov-05 09:21:48 Arno Garrels wrote:

Hello,

I'm actually writing a simple user manager component that I would like
to contribute to ICS. The component makes use of classes
TCollection/TCollectionItem to realize a tree-structure. A user group
contains accounts, accounts may have parameters.

Will they contains passwords?

To store or send component data I use XML format.
XML-text is written without the help of a third party component however
for parsing I use Stefan Heymann's TXmlScanner/TXmlParser
http://www.destructor.de. It appears to be the freeware solution with
less overhead. Should I better avoid use of XML and/or third party
components?

I think that it would be better to avoid third party components.
Dependencies can force the developer to have more components
installed that does the same think. So if I use two components that
need an XML parser and each use a different one then I'll have two
parser linked into my application.

Are there alternatives?

Why don't use the streaming capabilities of components?


Bye, Maurizio.

-- 
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


Re: [twsocket] UserManager component

2005-11-29 Thread Arno Garrels
Maurizio Lotauro wrote:
 On 28-Nov-05 09:21:48 Arno Garrels wrote:
 
 Hello,
 
 I'm actually writing a simple user manager component that I would like
 to contribute to ICS. The component makes use of classes
 TCollection/TCollectionItem to realize a tree-structure. A user group
 contains accounts, accounts may have parameters.
 
 Will they contains passwords?

Yes, with an option to save the MD5-hash only.

 
 To store or send component data I use XML format.
 XML-text is written without the help of a third party component however
 for parsing I use Stefan Heymann's TXmlScanner/TXmlParser
 http://www.destructor.de. It appears to be the freeware solution with
 less overhead. Should I better avoid use of XML and/or third party
 components?
 
 I think that it would be better to avoid third party components.
 Dependencies can force the developer to have more components
 installed that does the same think. So if I use two components that
 need an XML parser and each use a different one then I'll have two
 parser linked into my application.
 
 Are there alternatives?
 
 Why don't use the streaming capabilities of components?

The XML stuff is a hell. The only advantage of XML is that it can
be stored in a human readable form, every thing else is a pain.
I think I'll kick it out again.


---
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


Re: [twsocket] UserManager component

2005-11-28 Thread Angus Robertson - Magenta Systems Ltd
 To store or send component data I use XML format.
 XML-text is written without the help of a third party component 
 however
 for parsing I use Stefan Heymann's TXmlScanner/TXmlParser
 http://www.destructor.de. It appears to be the freeware solution with
 less overhead. Should I better avoid use of XML and/or third party
 components? 

I don't see any reason not to use other components, provided they have 
source code, no point in trying to redevelop something that works. 

 Are there alternatives? 

Some people may prefer to use a database to store user information.  
Ideally the component would be data storage independent, calling 
functions to create a user, check a user, etc, where those functions can 
be overloaded with XML, registry, SQL, INI files, or whatever a user 
prefers.  I'll contribute the SQL version g

Angus

-- 
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


Re: [twsocket] UserManager component

2005-11-28 Thread Arno Garrels
Angus Robertson - Magenta Systems Ltd wrote:
 To store or send component data I use XML format.
 XML-text is written without the help of a third party component
 however
 for parsing I use Stefan Heymann's TXmlScanner/TXmlParser
 http://www.destructor.de. It appears to be the freeware solution with
 less overhead. Should I better avoid use of XML and/or third party
 components?
 
 I don't see any reason not to use other components, provided they have
 source code, no point in trying to redevelop something that works.
 
 Are there alternatives?
 
 Some people may prefer to use a database to store user information.
 Ideally the component would be data storage independent, calling
 functions to create a user, check a user, etc, where those functions can
 be overloaded with XML, registry, SQL, INI files, or whatever a user
 prefers.  I'll contribute the SQL version g

Hmm that's interisting, my origin component was intended as 'in memory'
for a small amount of users, I'll try to make it more open, and will send
you the source for a review.

Arno
-- 
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