Ed Leafe wrote: > I apologize for not explaining myself more completely yesterday. > After working on this over the past few weeks, I finally got it all > working smoothly, and wanted to show it off. I probably should have > waited until today, and taken the time to explain things more clearly. > > First off, let's start calling it "web updating" or "easy updating" > instead of "auto-updating". For some reason, a few people read "auto" > and assumed that I had somehow morphed into Bill Gates and want to > take over control of your computers. I only used the term because to > my ear it sounded like it would signify "easy" updating. Apparently > others didn't read it that way. > > Let me state one thing at the start: there is absolutely *nothing* > in this feature that will *ever* change a single thing on your > computer without you explicitly telling it to do so. Period. So > please let's not hear more about Big Brother doomsday scenarios, OK? > A simple review of the code would have shown that clearly. >
Is it right that the setting comes from a user pref? Why not control this by code written by the developer? > Here's how it works. First, if you do nothing, nothing happens. It's > completely disabled by default. You have to turn it on first before Is it turned on by code written by the developer? > anything happens. This is just like many apps, such as Firefox, > iTunes, TortoiseSVN, BBEdit, and many others work; even Ubuntu and OS > X has this behavior. You can also control the frequency it will check > with the server for available updates. There is no GUI interface for > this right now, but constructing one won't be very difficult. When > the framework is first run, we could ask the user if they want to > check for updates or not, and save their preference; there will also > be a way to manually check for updates. > I'm not against update features for a app, but i am against updates for a framework. > OK, let's say that you turn on this update checking feature, and it > has been longer than your specified checking interval. Upon your next > launch of a Dabo app, it will call a web service to get the current > 'released' build number. You can call that service directly with > http://dabodev.com/frameworkVersions/latest and see that you get back > the current 'released' Subversion build number. > Why did you hardcode a web adress into the framework? What if someone needs the framework functionality in a intranet? Whats the point of a hardcode webadress for framework code? Again, this indicates that a tool function would be better. Why not create a dabo app (dabo-update) for this and put the necessary code into that? > BTW, I say 'released' in quotes because I'm not sure if this term is > confusing or clarifying. What I envision is a frequent pattern of > these build releases, with occasional point releases like we have > been doing all along. > > If the value of this build number is greater than the value of > dabo.version["revision"], that means that your copy of the framework > is out-of-date, and so you are presented with a dialog informing you > that an upgrade is available, and asking if you want to upgrade now. > If you answer 'No', nothing happens, and your app continues as it > normally would. You will not be asked to upgrade again until after > the interval you specified has passed. > > If you answer 'Yes', though, the framework asks the server for a > list of all changes since your current build, and will then update > your copy of the framework to the latest build. Your app then exits, > so that when you re-launch you are now running the current version of > the framework. > > As I mentioned in my other post on distribution, this will be > completely unnecessary for those running Subversion. The use case is > for those who are using Dabo to develop apps, or who are just > exploring and want to see if Dabo is for them. Here's a typical > scenario: > Again the above is an indication for a tool-functionality and not a framework functionality. If it would be a framework functionality you would have used properties to be able to configure the functionality. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 1) We release version 0.x.x and post it as the current release > > 2) Several weeks later, someone reads about Dabo and is interested. > They grab the 0.x.x version, which is by now out-of-date. > > 3) They run setup.py, and begin by launching DaboDemo, AppWizard, the > Class Designer, or any other Dabo app. > Maybe it would be better to use the existing python setuptools functions for this. > 4) They are presented with a dialog, asking if they want to enable > checking for updates, and if so, how often. They answer yes, and set > it to once a week. (This part is not done yet) > > 5) The app then checks the web service, and informs the user that > there is an update available. > > 6) The user OKs the update. After updating, they re-launch. > > 7) The user is now running the latest released build of Dabo, even > though the point release they downloaded was several weeks old. > > 8) A few days later, someone uncovers a bug in Dabo. I commit a > proposed fix to Subversion. > > 9) The fix I posted causes other unexpected problems, and a series of > Subversion commits ensue as I try to get things working right. > > 10) During this time the new user's system checks for an update. > Since we haven't marked a build as released yet, the web service > reports the same version it did the last time, and no update is > carried out. The user doesn't even see this happening. > > 11) A day or two later, I finally get everything working. The bug is > fixed, the side effects are gone, and everything is working OK. > > 12) At that point, I mark the current Subversion build as the latest > 'released' build. Only Paul and I are able to do this. > > 13) The next time the new user's system checks for updates, it will > find the new build, and ask the user if they want to update. > > 14) The user answers 'yes', and gets the bugfix update, avoiding all > of the bleeding-edge problems I caused by my faulty bugfix code. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > I hope that this post explains my vision more clearly, and can be > the basis for ideas on how to make this work as good as possible. It explained a lot. I think all this is a result of the way VFP people want to use it. This is not the way a python developer would do it. And i still think that it would be better to extract the functionality into a tool app instead of hardcoding it into the framework. If you plan to get an IDE at one point in time, why not adding it into the IDE? Uwe _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
