Hi Rob, thanks for your input... I intend to have both sytems, depending on the needs of the client. I am creating a system without a client/server process first.
Individual task files are not terribly large - they are just stored as text files with a specific extension, not as stacks. When a user grabs ownership of a task file, the task file is resaved to the drive, with the user's name included in the first item of that file. When another app tries to access the file, it first reads the first item to see if the file is owned by a different user. If it is, then the task file is viewed in a read-only mode that does not allow changes or saving. My brother, who is a much more experienced programmer than myself, gave me a long explanation about collisions, that can occur in the following order of events: 1) User A reads the file, and determines it is not owned 2) In the few milliseconds between when User A reads the file, and resaves it, user B reads the file and also reads that it is not owned. 3) User A makes changes and saves the data 4) User B, who should have been locked out but was not, makes changes and saves his data, overwriting the changes made by User A. My plan is to minimize the possibility of this type of collision by having the minimum possible time between reading a file and resaving it with ownership. Secondly, I will include some collision detection code that checks to make sure you are still the owner when you go to save a file. If you are not the owner, either because of a collision or because of the use of an ownership override, then you will be given the option to save the task under a different ID. It would be up to the two users to then merge their task files as needed. Client/Server is clearly superior in that it avoids this danger. However, client/server is much more involved, from the perspective of maintenance, set up, and cost. If a unit of a company wanted to set up Work Mage/Task Mage for their employees, they would just need to download the software and create a folder on a shared drive. I believe many users will be attracted to such ease-of-use. A Client/Server implementation will be necessary, however, and I plan to create that in the future. I am not sure if I would just create a Rev app that operates as the server, with or without a DB backend, or if I would have the client side program communicating directly with a multiuser DB program. I see advantages to both. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
