coapp-developers team mailing list archive

["Rivera, Rafael" <rafael@xxxxxxxxxxxxxxxxx>]

I understand legacy OSes are still in play, our product is actually
still hosted on Windows Server 2003, for various bureaucratic reasons.

But from my experience, these legacy servers/desktops are set up in very
specific, static configurations that won't be a candidate for CoApp use.
I'm just a little worried CoApp will be designed with OS-driven
limitations in mind only to have these OSes go away when CoApp reaches
maturity. Or worse, more people will use these OSes because of CoApp ;)

/rafael


On 4/7/2010 12:57 PM, Trevor Dennis wrote:
> XP/2003 don't support symbolic links at all.  Will junctions (hard links) be
> good enough?  
> 
>  
> 
> Don't discount XP and 2003 as old operating systems.  Coming from the
> corporate world (EDS and now HP), we have 60%+ desktops still on XP SP2/SP3
> and probably 90%+ on Windows 2003.  Some servers still on Windows 2000, and
> just a few are starting to move to 2008 as new hardware is purchased.  This
> is probably comparable to every other corporation out there (other than
> Microsoft itself).
> 
>  
> 
> If this project is going to work, it has to support XP SP3 at a minimum.  At
> least as long as Microsoft is supporting XP SP3.  I'd say even SP2 right now
> but they're dropping regular support for that this summer.
> 
>  
> 
> Trev.
> 
>  
> 
>  
> 
> From: coapp-developers-bounces+trevor=dennis-it.com@xxxxxxxxxxxxxxxxxxx
> [mailto:coapp-developers-bounces+trevor=dennis-it.com@xxxxxxxxxxxxxxxxxxx]
> On Behalf Of Garrett Serack
> Sent: Wednesday, April 07, 2010 10:22 AM
> To: Rivera, Rafael; coapp-developers@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Coapp-developers] Another kind of package
> 
>  
> 
> 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@xxxxxxxxxxxxxxxxxxx]
> 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