On 4/6/2010 1:52 PM, Trevor Dennis wrote:
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]>
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 apps store data in
their [/App_data] directory inside the web app… this isn’t as
uncommon as we think. 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
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]]
Sent: Tuesday, April 06, 2010 9:57 AM
To: Garrett Serack
Cc: [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]>
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)?
|
|
Garrett
Serack | Microsoft's Open Source Software
Developer | Microsoft Corporation
Office:(425)706-7939 email/messenger:
[email protected]
blog: http://fearthecowboy.com
twitter:
@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
Post to : [email protected]
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
--
Trevor Dennis
--
Trevor Dennis
_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
Ack - top-posting ;)
Yes, I really think that web applications need their own package,
putting them in program files is not only a pain because they might
need to write to configuration files/generate images/do other bad stuff
but it's also a security issue. For example apache makes you set up
specific
locations that are allowed to run scripts. I do NOT want that to be in
program files but somewhere else I can keep a tighter lock and key on.
In the PHP world GOOD application typically do NOT put their scripts in
the web root, but parallel to it (take a look at the general structure
that zend framework uses) - basically it sets up their own sub tree of
/application /config /lib /htdocs/www/whatever we call it this week
(the actual web root)
some kind of setup that uses
$base_web_location/<vendor>/<package>/<version> would
work fine, with each package having it's own webroot and virtual host
As to the last issue - the idea of "useful scripts" - maybe there needs
to be a place for general command line scripting stuff, as opposed to
lumping all 'desktop applications' together. To further complicate
things there is the idea of things in the PHP that script libraries
like PEAR and Zend Framework are installed to program files somewhere -
and then web applications that are installed put them into their
include_paths. In essence you're installing a "library" - but it's
going to have much different usage needs and patterns then a
traditional library/.dll
Ugh - too many ways to do things.
Thanks,
Elizabeth M Smith
|
