coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

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.com@xxxxxxxxxxxxxxxxxxx [mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Rivera, Rafael
Sent: Wednesday, April 07, 2010 11:01 AM
To: coapp-developers@xxxxxxxxxxxxxxxxxxx
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.com@xxxxxxxxxxxxxxxxxxx 
> [mailto:coapp-developers-bounces+garretts=microsoft.com@lists.launchpa
> d.net] On Behalf Of Rivera, Rafael
> Sent: Tuesday, April 06, 2010 6:46 PM
> To: coapp-developers@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp