>> Though, would we need "applications" Well, that's a good question. On one hand, Microsoft f'd up by putting wwwroot in inetpub as if there was only ever going to be one virtual root.
So, let's imagine what would have been a smarter idea:
inetpub
├───applications
│ ├───CoApp
│ │ ├───Gallery-2.0.7
│ │ └───phpBB-3.0.2
│ └───WordPress
│ ├───WordPress-4.3.6
│ └───WordPress-4.3.7
└───sites
├───bar.com
├───baz.org
└───foo.com
I'm just thinking it would be nice to separate 'apps' from 'sites' yet, keep it
all in a similar proximity.
I'm liking the version numbers idea. Good Call.
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: Trevor Dennis [mailto:[email protected]]
Sent: Tuesday, April 06, 2010 10:52 AM
To: Garrett Serack
Cc: [email protected]
Subject: Re: [Coapp-developers] Another kind of package.
Yeah, I see what you mean about the data directories and config files. If the
web apps wanted to follow any type of standard, they would have used /etc or
/usr/local/etc on UNIX boxes too.
I like your last approach then with \inetpub\applications\vendor\app. Though,
would we need "applications" in the path? I don't think it adds much except
another level. The vendor directory should remove any conflicts with local
software.
And should the app directory contain the version string in it? This would
allow multiple versions to be installed without wiping out the previous
configuration. When I deploy my web apps I always create new directories with
the new version, copy the needed app_data files, then point IIS admin at the
new folder. If it doesn't work, I can quickly point IIS back to the old one.
Definitely not under wwwroot. Most people who install IIS probably don't know
enough to secure that directory and default web site. It would expose entire
web sites that the user may not want published by default and under the wrong
URLs.
Trev.
On Tue, Apr 6, 2010 at 11:16 AM, Garrett Serack
<[email protected]<mailto:[email protected]>> wrote:
Arg. I see both sides of this. And I agree strongly with what you are saying.
(Although using Microsoft for a pattern of behavior is not always wise :D )
The odd duck out is (a lot) of PHP apps require some writable permissions in
their app directory. Hang on, even some ASP.NET<http://ASP.NET> apps store data
in their [/App_data] directory inside the web app... this isn't as uncommon as
we think. ASP.NET<http://ASP.NET> goes to the effort of automatically including
[/bin] [/App_Data] and [/App_Code] not servable to the web-yet accessible to
the app code.
And, both PHP and ASP.NET<http://ASP.NET> expect to be able to write their
configuration files in the same directory-(ie, settings.php or web.config) I
can't see how we can alter web app functionality to permit finding stuff like
that in [\ProgramData]. (Although, philosophically, they should)
>> I'd never expect a good web app to require a user to manually change the
>> included code files
You've just excluded nearly every PHP app I've used. Oh, wait you said "good
web app"... <grin> :D ... regardless, there isn't any way on the earth we can
expect to change & enforce that type of thing.
Hmmm. I do find it odd that SharePoint installs to [\Program Files], doesn't it
have a web.config?
I'm not afraid of setting a standard, but I'm loathe to violate the editable
files in [\Program Files] rule.
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: Trevor Dennis [mailto:[email protected]<mailto:[email protected]>]
Sent: Tuesday, April 06, 2010 9:57 AM
To: Garrett Serack
Cc:
[email protected]<mailto:[email protected]>
Subject: Re: [Coapp-developers] Another kind of package.
Hi,
I think I'd still prefer them to be under Program Files if possible. Windows
admins expect applications to be in a standard place and I don't think they
care too much if it's a windows app vs web app. Microsoft places all their web
apps under Program Files unless the user chooses otherwise. Eg. SharePoint,
WSUS, SQL Report Server.
Typically, a web app should not be changing its code files without using a
regular upgrade process like installing a new MSI. I know some like WordPress
will update their own files though through their admin interface. But
typically they just apply the same files that the new download would have put
in anyway. I'd never expect a good web app to require a user to manually
change the included code files. At least, not on any sort of production
machine. I don't see an issue with adding files to a web app like new template
files and stuff.
In either case, data files used by a web app should not be under the Program
Files directory. Probably under ProgramData except some goof at Microsoft
decided to make it hidden which encourages people to forget to back it up.
Trev.
On Tue, Apr 6, 2010 at 10:16 AM, Garrett Serack
<[email protected]<mailto:[email protected]>> wrote:
In the blueprints (http://coapp.org/Blueprints/Packages), I've outlined six
types of packages:
Applications & Services
(PHP, Apache, Gimp, Open Office)
System tools & shared utilities
(awk, grep, etc)
Libraries
(static libs)
Shared Libraries
(DLLs)
Plugins
(PHP extensions, Apache Modules, browser plugins)
Source Code
Device Drivers
I've been thinking there is another class of packages. I'm thinking along the
lines of WebApps. I'm not sure they belong in [\Program
Files\<publisher>\<application>] (like Applications), since they contain files
(PHP, ASPX, etc) that have a high likeliness of needing modifications-which is
heavily discouraged in [\Program Files].
The typical installation if they are using IIS would be
[\inetpub\wwwroot\<application>] but that makes a strong assumption that they
want it in the default web root.
We could make some assumptions and go with
[\inetpub\applications\<vendor>\<application>] regardless of webserver--Apache
or IIS could be easily configured to pick up the app from there (regardless of
virtual root or virtual app directory).
Ideas? Feedback?
And, is there a more generic case that this is part of-packages that are not
really executables, but large collections of files that are used to drive a
particular purpose (and aren't 'documents' either)?
[Description: fearthecowboy]<http://fearthecowboy.com/>
Garrett Serack | Microsoft's Open Source Software Developer | Microsoft
Corporation
Office:(425)706-7939 email/messenger:
[email protected]<mailto:[email protected]>
blog: http://fearthecowboy.com<http://fearthecowboy.com/>
twitter: @fearthecowboy<http://twitter.com/fearthecowboy>
I don't make the software you use; I make the software you use better on
Windows.
_______________________________________________
Mailing list:
https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
Post to :
[email protected]<mailto:[email protected]>
Unsubscribe :
https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
More help : https://help.launchpad.net/ListHelp
--
Trevor Dennis
--
Trevor Dennis
<<inline: image001.gif>>
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
