Some of you might already know that I've been planning to add support for modules in various parts of code:
- Events
- User- and group-files
- Cgis / Ftp & telnet commands
- Cookies (there are two types of cookies: objects and variables)
This is my master plan for userfiles:
1. Application reads primary UID list from passwd
2. Initialization routines of all available modules are being called
3. WM_FETCHUID is sent to internal message window to fetch UID list
4. GetFirstUid followed by loop of GetNextUid for selected module is run - duplicate user names and user ids are removed.
5. OpenUserFile is called when userfile is needed and it's not already open.
6. SyncUserFile, LockUserFile require exclusive access to userfile. Call is supposed to block until lock is granted.
(Proper implementation of lock/sync does not block infinitely. If exclusive lock to file could not be achieved within perioid of time, backup routine should be called before unlock, if changes were made) UnlockUserFile is called to free lock. It's guaranteed by ioFTPD that these procedures are called in thread safe order (Sync/Lock will wait until previous Sync finishes - or unlock is being called for pending lock), and that write is never called before lock.
7. Resources are to be freed on CloseUserFile
x. DeleteUser should fail if userfile is in use
y. WM_UPDATEUID is sent to notify daemon of renamed user
z. ioFTPD handles memory allocation for userfile structure
....... I'm not sure, if that made any sense
but that's how it'll be implemented (As an example, I'll propably convert current userfile algorithms to modules)
Suggested priority order:
1) Cookies - variables
2) Userfiles
3) Groupfiles
4) Cookies - objects
5) Events
6) Cgis / Ftp & telnet commands
.. back to bed