← Back to team overview

coapp-developers team mailing list archive

Re: Another kind of package.

 

>> 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:trevor@xxxxxxxxxxxxx]
Sent: Tuesday, April 06, 2010 10:52 AM
To: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx
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 <garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>> 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:trevor@xxxxxxxxxxxxx<mailto:trevor@xxxxxxxxxxxxx>]
Sent: Tuesday, April 06, 2010 9:57 AM
To: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
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 <garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>> 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: garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>
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     : coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers>
More help   : https://help.launchpad.net/ListHelp



--

Trevor Dennis



--

Trevor Dennis

GIF image


References