So it turns out that option #1 has another benefit. ** You can delete and recreate the symlink without having to stop the application running from that symlink'd folder. **
This will let you install side-by-side a new version of the application, remove the old symlink, and create a new one, without having to kill an existing process. Very Cool. Garrett Serack | Open Source Software Developer | Microsoft Corporation I don't make the software you use; I make the software you use better on Windows. -----Original Message----- From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net [mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On Behalf Of Rivera, Rafael Sent: Wednesday, April 07, 2010 11:01 AM To: coapp-developers@lists.launchpad.net Subject: Re: [Coapp-developers] Another kind of package Yep yep. Option 1 has definitely grown on me now, sorry Elizabeth. :) /rafael On 4/7/2010 12:21 PM, Garrett Serack wrote: > Arg! > > We're absolutely trying to avoid relying on LUAFS (the component that > silently virtualizes writes out of [\Program Files]). The purpose of that is > for backward app compatibility -future work should definitely avoid the use > of that. Anyway I'm pretty sure that Windows Server 2003 R2 is in active > support until December 2015. > > I like the idea of <vendor>\<app>\<version> too, but one of my goals > was to have the ability to symlink the current version to a > predictable well-known-path, and I'd like to use the same pattern for > all aspects of location determination. (web apps, desktop apps, > libraries, docs, etc) > > I've sketched out some ideas: > > The first (under option1), was my original idea-well-known-path points to a > specific sibling version. This is nice, predictable, and easy to change a > path somewhere to switch over to a specific version if required, otherwise > the 'unversioned' path is authoritative. This is similar to common > conventions in Linux. > > The second (under option2) doesn't present an obvious way to have an > authoritative version, short of making a 'current' symlink in the same > directory. > > The third (under option3) is kind of a compromise-there still is an > authoritative version, and all the different versions roll up under a common > directory. I'm not very keen on it, but it's not bad. > > > +---option1 > | +---openssl -- symlink to openssl-0.98j > | +---openssl-0.98i > | +---openssl-0.98j > | +---zlib -- symlink to zlib-1.23 > | +---zlib-1.23 > | +---zlib-1.25 > | > +---option2 > | +---openssl > | | +---0.98i > | | +---0.98j > | +---zlib > | +---1.23 > | +---1.25 > | > +---option3 > +---openssl -- symlink to [openssl]\0.98j > +---zlib -- symlink to [zlib]\1.25 > +---[openssl] > | +---0.98i > | +---0.98j > +---[zlib] > +---1.23 > +---1.25 > > > Ideas? > > Garrett Serack | Open Source Software Developer | Microsoft > Corporation I don't make the software you use; I make the software you use > better on Windows. > > From: > coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net > [mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpa > d.net] On Behalf Of Rivera, Rafael > Sent: Tuesday, April 06, 2010 6:46 PM > To: coapp-developers@lists.launchpad.net > Subject: Re: [Coapp-developers] Another kind of package > > I'm new to the conversation, so I don't have quoted material -- apologies. > > Program Files\ hosting > Starting with Windows Vista and Windows Server 2008, we have virtualization > that silently takes over and redirects (for appcompat reasons) writes to the > caller's virtual application store. With Windows XP and Windows Server 2003 > fading away, is hosting in Program Files\ really a problem? I think we can > safely assume that users with this type of virtualization turned off within > the candidate OSes are super advanced/asking for trouble and therefore > shouldn't be considered in the design process. It's impossible to please > everyone. > > Directory structure > I like Elizabeth's approach of dropping versions (e.g. 1.0, 1.1) into an > authoritative <vendor>\<app> folder. I'd imagine this is neater, especially > when dealing with faster updating applications (or lots of installed > applications). > > /rafael > _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
