On 1/3/07, Ed Leafe <[EMAIL PROTECTED]> wrote: > There are too many things that need to be worked on that either > aren't working or haven't been created yet to start mucking around > with something that is working just fine without any solid reason to > change it. So unless you can clearly demonstrate a case where a > reasonable action by a developer causes a problem in Dabo, let's > consider this issue closed.
I have encountered problems with decisions on how to refer to user data vs application data in an application I worked on for a while, but that was with a framework we had to build from scratch. Here is what I remember vaguely off the top of my head from that time as to our intentions: We did not want the users to move application data around, so we put as much of it as possible inside our virtual file system that we wrapped up and distributed to the user in one file. We could not avoid some of this information escaping outside of the virtual file system into registry and environment variables. In my opinion, changing the registry and requiring environment variables changes on something I am releasing is bad. I hope they've since fixed that. With respect to user data, we were building an app that users would be generating a lot of data for. Some of this data lived in the file system, such as: data that represented an item under test, test scripts generated for an item through interaction with our app and the items, test logs generated from running these scripts, captured image data from test results, and report data that referred to the test scripts, the items, the images, and the logs. Some of this data was stored in a database, some of it in a file system, and it was an ongoing discussion about the merits of where we wished to persist things and how much control we should give to the user, and what we would expect the user experience to be if we allows them to move something--would the user consider our app "broken" if they moved the data out from underneath us and thus were not able to view the reports, for example. Or perhaps be able to run a scripts, etc. So, I don't agree that is necessary a vague and ill defined problem; however, not all of it will be dabo's responsibility. I think most of it is the onus of the application developers and will depend on the requirements they set for their application and the contract with their costumers. I am not sure of the requirements between dabo and the application developer. What I would expect from you is that you do not interfere with the strategy I use when deciding to store application data and user data. So as long as you don't munge that, great. Which I don't see anyone complaining about yet. I apologize for following up to this after you considered the matter closed, but after reading the thread I did not feel that everything was addressed, since you said you did not see specific valid application developer and/or user use cases from Carl. -- sheila _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
