'Automatic' Software Upgrades
James Sargent
how feasible it would be to write a program to automatically upgrade the
software on your machine.
What I envisage is something like this:
An application directory contains an an extra file called something like
!Upgrade or !Home which has details of the version of the program,
contact details for the program's author(s) and where it could (last) be
found on the 'web.
You start the !Upgrader application, drag your application on to it and
this file gets read. Providing you're online, !Upgrader goes off and
checks for later versions at the defined location on the web.
If it finds a newer version, it offers to download the file for the
user. I imagine some applications could be upgraded automatically and
some would the require some manual intervention.
If !Upgrader (or whatever it might be called) remembered the locations
of the applications on your hard disc (or appropriate system variables)
then it would be possible for it to check against a whole range of
installed applications automatically.
What do you think? Is it possible? Would it benefit people?
Regards,
James
John Duffell
James Sargent <jssa...@uk.orracle.com> wrote:
> I was wondering, as it's something beyond my RISC OS authoring skills,
> how feasible it would be to write a program to automatically upgrade the
> software on your machine.
>
> What I envisage is something like this:
>
[snip]
>
> What do you think? Is it possible? Would it benefit people?
Sounds useful, yes, perhaps it could run every night, say, and email you to
say that the thing was updated, and has been downloaded to 'x', then perhaps
you could run it and it'd give a window allwing you to upgrade. It would
have to store old version, so it could provide a "revert" option!
HTH,
--
John
http://duffell.cjb.net/ http://www-users.york.ac.uk/~jwd104/
Martin Dann
> I was wondering, as it's something beyond my RISC OS authoring skills,
> how feasible it would be to write a program to automatically upgrade the
> software on your machine.
This would be very easy to implement.
(Stuart Halliday supplies a url file for his applications).
> What I envisage is something like this:
>
> An application directory contains an an extra file called something like
> !Upgrade or !Home which has details of the version of the program,
> contact details for the program's author(s) and where it could (last) be
> found on the 'web.
Or even !info, a general infomation file in your applicaton.
> You start the !Upgrader application, drag your application on to it and
> this file gets read. Providing you're online, !Upgrader goes off and
> checks for later versions at the defined location on the web.
>
> If it finds a newer version, it offers to download the file for the
> user. I imagine some applications could be upgraded automatically and
> some would the require some manual intervention.
You will often want to make a backup of the original first,
or copy personal setting out (if the app dosn't use choices:).
> If !Upgrader (or whatever it might be called) remembered the locations
> of the applications on your hard disc (or appropriate system variables)
> then it would be possible for it to check against a whole range of
> installed applications automatically.
you don't want it too automated, as you might suddenly find that you
have a copy of socketeer that dosn't work on your machine.
> What do you think? Is it possible? Would it benefit people?
Yes it would, I was looking into a similar idea at the beginning of
the year, but slowed down as half of csa.programmer seemed to
want an XML version, and the other half a standard messages file.
http://www.f451.freeserve.co.uk/InfoRFC.txt
http://groups.google.com/groups?threadm=I%40f451.freeserve.co.uk
Martin.
--
Typed by monkey #27662472869676 on typewriter #7552416572242
John Duffell
Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> In message <3CF753C1...@uk.orracle.com>
> James Sargent <jssa...@uk.orracle.com> wrote:
>
[snip]
> >
> > If it finds a newer version, it offers to download the file for the
> > user. I imagine some applications could be upgraded automatically and
> > some would the require some manual intervention.
>
> You will often want to make a backup of the original first,
> or copy personal setting out (if the app dosn't use choices:).
All apps use Choices nowadays, otherwise they are broken. Exceptions may be
resource directories, but I suspect there are few of those.
[snip]
Nick Boalch
> I was wondering, as it's something beyond my RISC OS authoring skills,
> how feasible it would be to write a program to automatically upgrade the
> software on your machine.
I made some noises about this sort of thing -- a central package repository
and software with similar functionality to Debian's apt system, but nobody
seemed very interested.
N.
--
Allen: Give yourself permission to open up. What were your parents like?
Angel: My parents were great. Tasted a lot like chicken.
-- Tim Minear, "Angel", 'Sense and Sensitivity'
Stefan Bellon
> On 31 May 2002, James Sargent <jssa...@uk.orracle.com> wrote:
> > I was wondering, as it's something beyond my RISC OS authoring
> > skills, how feasible it would be to write a program to
> > automatically upgrade the software on your machine.
> I made some noises about this sort of thing -- a central package
> repository and software with similar functionality to Debian's apt
> system, but nobody seemed very interested.
A system like Debian's apt would be *very* interesting. But all the
suggestions I heard till now, are far away from what apt can do.
--
Stefan Bellon * <mailto:sbe...@sbellon.de> * <http://www.sbellon.de/>
PGP 2 and OpenPGP keys available from my home page
Hi! I'm a .signature virus!
Copy me into your ~/.signature to help me spread!
Nick Boalch
> > > I was wondering, as it's something beyond my RISC OS authoring
> > > skills, how feasible it would be to write a program to
> > > automatically upgrade the software on your machine.
>
> > I made some noises about this sort of thing -- a central package
> > repository and software with similar functionality to Debian's apt
> > system, but nobody seemed very interested.
>
> A system like Debian's apt would be *very* interesting. But all the
> suggestions I heard till now, are far away from what apt can do.
I don't think we want to get too complex. ;-)
I'd envisage something with the functionality of apt-get update (maintaining
a database of packages and version numbers), apt-get install (installing new
packages) and apt-get upgrade (upgrading installed packages), although I'd
make the install functionality merely fetch archives rather than installing,
since RISC OS's application model is so different to Linux's.
If anyone with RISC OS programming skills feels like pursuing this further
then please feel free to contact me!
N.
--
If cryptography is outlawed, only outlaws wifo4(F9%!98f3((hg$;'da"d;f+
Stephen Courtney
Stefan Bellon <sbe...@sbellon.de> wrote:
> Nick Boalch wrote:
> > On 31 May 2002, James Sargent <jssa...@uk.orracle.com> wrote:
> > > I was wondering, as it's something beyond my RISC OS authoring
> > > skills, how feasible it would be to write a program to
> > > automatically upgrade the software on your machine.
> > I made some noises about this sort of thing -- a central package
> > repository and software with similar functionality to Debian's apt
> > system, but nobody seemed very interested.
> A system like Debian's apt would be *very* interesting. But all the
> suggestions I heard till now, are far away from what apt can do.
What about NetWatch? - see:
http://home.student.utwente.nl/m.m.bezemer/netwatchuk.html
It links in with the ANS Filebase (http://filebase.acornusers.org), but you
can also add other sites to watch.
Cheers,
Stephen
--
Stephen Courtney - Barti on #acorn #altb5uk
Home | http://www.steve-c.co.uk
Acorn News Service | http://www.acornusers.org/ans
RISC OS Filebase | http://filebase.acornusers.org
The IconBar | http://www.iconbar.com
Nick Boalch
> I'd envisage something with the functionality of apt-get update
> (maintaining a database of packages and version numbers), apt-get install
> (installing new packages) and apt-get upgrade (upgrading installed
> packages), although I'd make the install functionality merely fetch
> archives rather than installing, since RISC OS's application model is so
> different to Linux's.
Actually, thinking about it, I /would/ want automatic package installation.
The "RISC OS apt" should install things that /have/ to go into certain
locations (such as !Boot.Resources or wherever) automatically and then
allow you to drag-and-drop other components to wherever you want to keep
them.
A system of this sort would be a godsend for installing something like Zap,
and would also remove the need for packages to either be shipped with or
contain separate download/installation instructions for shared components
such as !JFShared or !WBModules, since you'd just make them dependant
within the package database.
The more I think about a system like this the more I want it. There must
be a programmer somewhere with some free time. ;-)
Incidentally, I'm quite happy to do the server-side functionality if
someone wants to write the RISC OS fat client.
N.
--
Buffy: You don't know what you mean. You don't know what feelings are!
Spike: I damn well do. I lie awake every night...
Buffy: You sleep during the day!
-- David Fury, "Buffy the Vampire Slayer", 'Crush'
Nick Boalch
> I'd envisage something with the functionality of apt-get update
> (maintaining a database of packages and version numbers), apt-get install
> (installing new packages) and apt-get upgrade (upgrading installed
> packages), although I'd make the install functionality merely fetch
> archives rather than installing, since RISC OS's application model is so
> different to Linux's.
Actually, thinking about it, I /would/ want automatic package installation.
Martin Dann
Simon John <ro...@127.0.0.1> wrote:
> In article <539e593...@lorca.frejol.org>,
> Nick Boalch <n.g.b...@durham.ac.uk> wrote:
>
> [snip]
>
> > > I was wondering, as it's something beyond my RISC OS authoring skills,
> > > how feasible it would be to write a program to automatically upgrade the
> > > software on your machine.
>
> > I made some noises about this sort of thing -- a central package repository
> > and software with similar functionality to Debian's apt system, but nobody
> > seemed very interested.
>
> Sounds like the product of Satan's loins to me!
>
> I've seen so many people's computers screwed by Window's Update, and even I
> have had a Linux box screwed by Ximian RedCarpet.
Like on one setup, where the poweron autodetection detected
the mouse connected, and installed a mouse driver.
It would have been better if it didn't do this every time the pc was
turned on.
I like to know what is happening with *my* computer, not some software
author who wants to replace toolbox 1.63 with toolbox 0.21.
Martin.
--
According to the human genome project, humans are 50-60% bananas.
Nick Boalch
> I like to know what is happening with *my* computer, not some software
> author who wants to replace toolbox 1.63 with toolbox 0.21.
This is exactly why a system like apt is a *good* idea. Authors don't
package shared modules such as toolbox with their software: you simply
note that the package depends on the presence of the toolbox and your
computer keeps you up to date with the latest version.
It also means that if you want to install, say, Zap, you just say
"install zap" and the computer checks the latest version, fetches it
and installs it, instead of you having to hunt round the internet for
it and then work out where the different bits go on your system.
N.
--
Tony Blair is reported to be detained indefinitely under plans unveiled by
the Home Secretary.
-- Corrupt Teletext page
Iain Williamson
John Duffell <jwd...@york.ac.uk> wrote:
> In message <da94a3f4b%Mar...@f451.freeserve.co.uk>
> Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
>
> > In message <3CF753C1...@uk.orracle.com>
> > James Sargent <jssa...@uk.orracle.com> wrote:
> >
> [snip]
> > >
> > > If it finds a newer version, it offers to download the file for the
> > > user. I imagine some applications could be upgraded automatically and
> > > some would the require some manual intervention.
> >
> > You will often want to make a backup of the original first,
> > or copy personal setting out (if the app dosn't use choices:).
>
> All apps use Choices nowadays, otherwise they are broken. Exceptions
> may be resource directories, but I suspect there are few of those.
Broken? That seems a bit strong. Granted, I'm not active on this platform,
but I've not seen a missive stating that apps must use the choices: path
for user data. I'm aware that it's good practice, but not following good
practice don't make it broke.
As for resource files, they should contain no user data. Unless someone
has been effectively developing the application (e.g. further localising
the resource strings) I'd not expect the resources files to change.
--
To avoid being sent to a communal spam bin, remove the XXX
to e-mail me. You'll get a quicker response --- Iain Williamson
John Duffell
Iain Williamson <iai...@rednova.demon.co.uk> wrote:
> In message <c844533...@localhost.duffellj.freeserve.co.uk>
> John Duffell <jwd...@york.ac.uk> wrote:
>
[snip]
> >
> > All apps use Choices nowadays, otherwise they are broken. Exceptions
> > may be resource directories, but I suspect there are few of those.
>
> Broken? That seems a bit strong. Granted, I'm not active on this platform,
> but I've not seen a missive stating that apps must use the choices: path
> for user data. I'm aware that it's good practice, but not following good
> practice don't make it broke.
Applications should write to themselves, they should assume that they are
read only. The choices system has been in use for over five years, and there
is absolutely no reason not to use it, very few applications make no attempt
to use it, although many make a very bad job of it ;) I feel quite safe in
calling any program which doesn't work according the the choices spec broken.
For the topic in hand, I'd say it would be safe to ignore applications which
don't follow the system, to make the system more simple and relaible, and any
non-conforming applications will have to be manually upgraded (the author
would have to add the !Info file or whatever, so they may as well fix the
choices issue at the same time, if any!) :)
As you say, there's never been any missive AFAIK, but these things gradually
in the eyes of developers as time goes by, otherwise we're all stuck in RISC
OS 3.1 forever :)
> As for resource files, they should contain no user data. Unless someone
> has been effectively developing the application (e.g. further localising
> the resource strings) I'd not expect the resources files to change.
How about things like !ARMovie, !System, !ZapFonts etc?
BFN,
Iain Williamson
John Duffell <jwd...@york.ac.uk> wrote:
> In message <75117e3...@rednova.demon.co.uk>
> Iain Williamson <iai...@rednova.demon.co.uk> wrote:
>
> > In message <c844533...@localhost.duffellj.freeserve.co.uk>
> > John Duffell <jwd...@york.ac.uk> wrote:
> >
> [snip]
> > >
> > > All apps use Choices nowadays, otherwise they are broken. Exceptions
> > > may be resource directories, but I suspect there are few of those.
> >
> > Broken? That seems a bit strong. Granted, I'm not active on this
> > platform, but I've not seen a missive stating that apps must use the
> > choices: path for user data. I'm aware that it's good practice, but
> > not following good practice don't make it broke.
>
> Applications should write to themselves, they should assume that they
> are read only. The choices system has been in use for over five years,
> and there is absolutely no reason not to use it, very few applications
> make no attempt to use it, although many make a very bad job of it ;)
Seconded
> I feel quite safe in calling any program which doesn't work according
> the the choices spec broken.
Possibly. I suppose there is a spec out there (even if I've never seen
it).
> For the topic in hand, I'd say it would be safe to ignore applications
> which don't follow the system
[snip]
Good idea, I think.
>
> As you say, there's never been any missive AFAIK, but these things
> gradually in the eyes of developers as time goes by, otherwise we're all
> stuck in RISC OS 3.1 forever :)
I'm probably being too picky - like you say, information is expected to
just autonomously percolate. It'd too optimistic to expect otherwise.
>
> > As for resource files, they should contain no user data. Unless someone
> > has been effectively developing the application (e.g. further localising
> > the resource strings) I'd not expect the resources files to change.
>
> How about things like !ARMovie, !System, !ZapFonts etc?
Let me add 'in normal use' to that sentence of mine - yes, those'll change
if anyone's upgrading modules, or adding codecs or fonts (a form of
upgrading) but there should still be no user data in there.
Though the directories in Boot:Resources tend to be upgraded by the user,
so they might need to be excluded from an automatic upgrade system, or
treated as special cases (!System). I was only really referring to
application resources originally (such as those created by ResEd) - but I
think it carries.
Ian K
Nick Boalch <n.g.b...@durham.ac.uk> wrote:
> On 31 May 2002, Nick Boalch <n.g.b...@durham.ac.uk> wrote:
> Actually, thinking about it, I /would/ want automatic package
> installation. The "RISC OS apt" should install things that /have/ to go
> into certain locations (such as !Boot.Resources or wherever)
> automatically and then allow you to drag-and-drop other components to
> wherever you want to keep them.
> A system of this sort would be a godsend for installing something like
> Zap, and would also remove the need for packages to either be shipped
> with or contain separate download/installation instructions for shared
> components such as !JFShared or !WBModules, since you'd just make them
> dependant within the package database.
> The more I think about a system like this the more I want it. There must
> be a programmer somewhere with some free time. ;-)
> Incidentally, I'm quite happy to do the server-side functionality if
> someone wants to write the RISC OS fat client.
I have had a project on the back burner for some time along these lines.
It has been getting rather large and unwieldily due to me trying to cope
with the variety of different boot structures people have and trying to
include a full array of features.
I must do some more work on it and get at least a simplified version
released.
Regards
Ian K
John Duffell
Iain Williamson <iai...@rednova.demon.co.uk> wrote:
> In message <70a6bf3...@localhost.duffellj.freeserve.co.uk>
> John Duffell <jwd...@york.ac.uk> wrote:
>
> > In message <75117e3...@rednova.demon.co.uk>
> > Iain Williamson <iai...@rednova.demon.co.uk> wrote:
> >
[snip]
>
> > I feel quite safe in calling any program which doesn't work according
> > the the choices spec broken.
>
> Possibly. I suppose there is a spec out there (even if I've never seen
> it).
Look on http://www.movspclr.co.uk/ there's one there but it's a little
outdated now IIRC.
[snip]
> > >
> > > As for resource files, they should contain no user data. Unless someone
> > > has been effectively developing the application (e.g. further
> > > localising the resource strings) I'd not expect the resources files to
> > > change.
> >
> > How about things like !ARMovie, !System, !ZapFonts etc?
>
> Let me add 'in normal use' to that sentence of mine - yes, those'll change
> if anyone's upgrading modules, or adding codecs or fonts (a form of
> upgrading) but there should still be no user data in there.
Yes, but that's not the point; the point is that if you want to upgrade the
shell ZapFonts then you would have to copy across any fonts the user has
which aren't in the new distribution. Whether it's user data or not is not
particularly relevent, it's the fact that there's data which in not part of
the original program stored within the program.
> Though the directories in Boot:Resources tend to be upgraded by the user,
> so they might need to be excluded from an automatic upgrade system, or
> treated as special cases (!System). I was only really referring to
> application resources originally (such as those created by ResEd) - but I
> think it carries.
Well I'd be in favour of ignoreing resource type applications, and perhaps
making a separate system. However, I'm not sure how often the shell part
changes anyway, maybe they can be hndled some how else.
John Duffell
Paul Vigay <spam...@vigay.com> wrote:
> In article <ab00034...@rednova.demon.co.uk>, Iain Williamson
> <URL:mailto:iai...@rednova.demon.co.uk> wrote:
[I wrote the following - careful about snipping attributions for text which
is still there!]
> > > Applications should write to themselves, they should assume that they
> > > are read only. The choices system has been in use for over five years,
> > > and there is absolutely no reason not to use it, very few applications
> > > make no attempt to use it, although many make a very bad job of it ;)
> >
> > Seconded
>
> What happens if you want to run more than one copy of the same application
> at the same time? Should applications detect to see if an instance is
> already running and then create a second (third, forth etc) choices
> directory inside boot:choices?
No; applications should not care what other programs are running, multiple
instances should just use the same choices. If there's need for a
multi-feature then it's usually built in, e.g. profiles in socketeer, or
separate switchable printer drivers, although these are both bad examples in
that they IIRC exclude other copies from being run.
Iain Williamson
John Duffell <jwd...@york.ac.uk> wrote:
> In message <ab00034...@rednova.demon.co.uk>
> Iain Williamson <iai...@rednova.demon.co.uk> wrote:
>
> > In message <70a6bf3...@localhost.duffellj.freeserve.co.uk>
> > John Duffell <jwd...@york.ac.uk> wrote:
> >
> > >
> > > How about things like !ARMovie, !System, !ZapFonts etc?
> >
> > Let me add 'in normal use' to that sentence of mine - yes, those'll
> > change if anyone's upgrading modules, or adding codecs or fonts (a
> > form of upgrading) but there should still be no user data in there.
>
> Yes, but that's not the point; the point is that if you want to upgrade
> the shell ZapFonts then you would have to copy across any fonts the user
> has which aren't in the new distribution. Whether it's user data or not
> is not particularly relevent, it's the fact that there's data which in
> not part of the original program stored within the program.
Yes, I'd already conceded that point below:
>
> > Though the directories in Boot:Resources tend to be upgraded by the
> > user, so they might need to be excluded from an automatic upgrade
> > system, or treated as special cases (!System). I was only really
> > referring to application resources originally (such as those created
> > by ResEd) - but I think it carries.
>
> Well I'd be in favour of ignoreing resource type applications, and
> perhaps making a separate system.
Resource type applications? Like !System or !ARMovie? I'd think any
upgrading system that can't cope with upgrading the user's !System is
rather underspecified.
> However, I'm not sure how often the
> shell part changes anyway, maybe they can be hndled some how else.
You've lost me there. I could make a guess, but I'd rather not risk
arguing against myself. Shell part?
Iain Williamson
Paul Vigay <spam...@vigay.com> wrote:
> In article <ab00034...@rednova.demon.co.uk>, Iain Williamson
> <URL:mailto:iai...@rednova.demon.co.uk> wrote:
[ As already noted, I didn't write the following - John did ]
> > > Applications should write to themselves, they should assume that
> > > they are read only. The choices system has been in use for over
> > > five years, and there is absolutely no reason not to use it, very
> > > few applications make no attempt to use it, although many make a
> > > very bad job of it ;)
> >
> > Seconded
>
> What happens if you want to run more than one copy of the same
> application at the same time? Should applications detect to see if an
> instance is already running and then create a second (third, forth etc)
> choices directory inside boot:choices?
>
It makes no difference to how many copies of the application are running -
say two copies of the same program are running and writes/reads its
settings from choices: (including temporary unsaved settings, for the sake
of argument). Assuming it only uses one settings directory in choices:
each copy would overwrite files from the other. Yet even if it saved its
files inside the application directory exactly the same overwriting would
occur (assuming the FS permitted it to write there).
Applications which do save temporary files to disc should do as you
suggest - create second (third, fourth etc.) spaces for files to be saved,
either in Choices: or the application directory - or (more reasonably)
use !Scrap, where such files are meant to be stored.
For legitimate stored settings, it makes sense to use one shared space for
the default (saved) settings. If it did use a secondary space for saving
the settings of a second instance, you'd have to always load a second
instance before those settings were retreived - very counter-intuitive.
The only situation where it would make a difference whether it used
Choices: or the app directory is if there were two separate copies of the
application on disc - hence if each copy was loaded each would use a
different application directory if saving there, yet use a shared choices:
directory if it was saving there.
This to me is one of the main advantages of using Choices: - I can archive
an old version of an app off to my InactivRes directory (for deleting
after my next backup) and unzip a the new version which will now pick up
my old settings straight away.
There may be *unusual* situations where you wouldn't want two copies of
the same app, in different directories, to share the same settings - those
situations where saved settings are related in some way to the location of
the application. The most common situation I can think of is where the
application saves some user files inside or alongside the app directory
and the saved settings specify which user file is the default to be loaded
(though we've already said that applications should assume they are on a
read-only medium, so this ideally shouldn't happen). In these situations,
yes it must be possible to store multiple sets of settings, each tied to a
specified installation location.
Using choices: for storing settings does commonly introduce one
complication though - compatibility of those files. Once they are shared,
different versions of the same application could be attempting to use
those files, so settings files should be designed with forward
compatiblity in mind (in markup or whatever format), so that new versions
of said file can be extended and remain backwards compatible.
Sorry about the length of that - but I think I've covered all bases.
John Duffell
Iain Williamson <iai...@rednova.demon.co.uk> wrote:
[snip sensible stuff]
>
> There may be *unusual* situations where you wouldn't want two copies of
> the same app, in different directories, to share the same settings - those
> situations where saved settings are related in some way to the location of
> the application. The most common situation I can think of is where the
> application saves some user files inside or alongside the app directory
> and the saved settings specify which user file is the default to be loaded
> (though we've already said that applications should assume they are on a
> read-only medium, so this ideally shouldn't happen). In these situations,
> yes it must be possible to store multiple sets of settings, each tied to a
> specified installation location.
That can be covered using document files, I think, e.g. where you can save
out like, say, a URI file from oregano then you can load it in if you want a
different (home) page loaded (on startup) or whatever. Two copies of the
program still seems unnecessary. However, since it is obscure cases, I can't
tell what would be appropriate.
[snip]
HTH,
John Duffell
Iain Williamson <iai...@rednova.demon.co.uk> wrote:
> In message <6b82424...@localhost.duffellj.freeserve.co.uk>
> John Duffell <jwd...@york.ac.uk> wrote:
>
> > In message <ab00034...@rednova.demon.co.uk>
> > Iain Williamson <iai...@rednova.demon.co.uk> wrote:
> >
[snip]
> > > Though the directories in Boot:Resources tend to be upgraded by the
> > > user, so they might need to be excluded from an automatic upgrade
> > > system, or treated as special cases (!System). I was only really
> > > referring to application resources originally (such as those created
> > > by ResEd) - but I think it carries.
> >
> > Well I'd be in favour of ignoreing resource type applications, and
> > perhaps making a separate system.
>
> Resource type applications? Like !System or !ARMovie? I'd think any
> upgrading system that can't cope with upgrading the user's !System is
> rather underspecified.
Well I wasn't meaning it wouldn't be upgraded at all, it could be invoked as
a plugin or something, I was jusit meaning we shouldn't provide that sort of
functionality for all apps, just for the minimum number of special cases,
perhaps as a different application. Anyway, what's wrong with !Boot's
system/fonts merge functions? I thought the whole ide was to be able to
check that general applications were up to date - there's not one single
version of system which is the most up to date. We may as well handle 99% of
the useful stuff rather than worry about 1% of it for 50% of the time?
Comments? As I say, it could all appear to be transparent from a user view.
> > However, I'm not sure how often the
> > shell part changes anyway, maybe they can be hndled some how else.
>
> You've lost me there. I could make a guess, but I'd rather not risk
> arguing against myself. Shell part?
As in the !Run, !Boot, !Help etc. files, the part which isn't the actual
resource.
HTH,
druck
> It makes no difference to how many copies of the application are running -
> say two copies of the same program are running and writes/reads its
> settings from choices: (including temporary unsaved settings, for the sake
> of argument). Assuming it only uses one settings directory in choices:
> each copy would overwrite files from the other. Yet even if it saved its
> files inside the application directory exactly the same overwriting would
> occur (assuming the FS permitted it to write there).
Its usually the last saving of choices takes precedence, which is easy for
the user to understand.
If its a really clever program it should read in the choices just before
modifying them, so that it only alters the particular options the user has
changed at that time, and doesn't just revert all settings back to the state
they were when it was run.
> Applications which do save temporary files to disc should do as you
> suggest - create second (third, fourth etc.) spaces for files to be saved,
> either in Choices: or the application directory - or (more reasonably)
> use !Scrap, where such files are meant to be stored.
Which means that you'd have to run a second, third or forth copy to be able
to access these choices, which could cause confusion. It is better not to
rely on the order of multiply run applications. If several distinct groups of
choices are required, it should be an option in the program to save these on
a named basis and be able to reload them in to an arbitary copy.
---druck
--
The ARM Club * http://www.armclub.org.uk/
James Sargent
> I like to know what is happening with *my* computer, not some software
> author who wants to replace toolbox 1.63 with toolbox 0.21.
That's not really what I had in mind. Just a system that says "you're on
version x of a certain program and version y is now available, shall I
download it for you" would be a good start.
Additionally, you would hope that a utility like this wouldn't let you
'downgrade' related items.
Regards,
James