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 W
Just an FYI.
The CoApp wiki will be going down on Wednesday afternoon, and be out probably
until Saturdayish. (we're moving the lab, where it's currently hosted, and I
haven't got the VM moved to a hosting facility yet (not ready!)
I'll probably just put up an FYI "We're moving" page for a coup
ES>> I dunno - some things unix doesn't get right in my opinion. Any reason
not do to / - so you have wordpress with your 15
million versions inside named wordpress-1.5 and wordpress-2.0 etc etc etc.
Well, the only reason I can think of, is that in the spec currently, for
include/doc/resources
>> I don't think it's really a "web library" if you have to edit it.
Good Point.
>> maybe we just need to always put the neutral stuff in just plain program
>> files sigh
Me too... *sigh*
The other choice is to make another [\Program Files (any)] to go along with
[\Program Files (x86)] an
On 4/6/2010 4:00 PM, Garrett Serack wrote:
ES>> Except then you run into things that AREN'T web apps being
written in a web language using a library.
ES>> PHP-GTK and PyGTK scripts, pyrus/pear packaging code, phpunit
test suites
ES>> - they all want to use libraries that aren't necessarily con
ES>> Except then you run into things that AREN'T web apps being written in a
web language using a library.
ES>> PHP-GTK and PyGTK scripts, pyrus/pear packaging code, phpunit test suites
ES>> - they all want to use libraries that aren't necessarily confined to web
space.
TD>> For libraries, shoul
That's strange. It's much easier and quicker to read a person's reply right
at the top of the message instead of scrolling all the way down through the
15 pages of conversation to get the new piece. Especially when you get on a
mobile phone. It's only bad when you're new to an old conversatio
On 4/6/2010 2:23 PM, Garrett Serack wrote:
Bottom Poster!???!! Arg! I preferred bottom-posting, but in my world,
it's just not done.
Heh - in the open source world you get your head taken off for it (sigh)
>> $base_web_location///
...\applications\\ or ... \applications \\\?
Pa
Bottom Poster!???!! Arg! I preferred bottom-posting, but in my world, it's
just not done.
>> $base_web_location///
...\applications\\ or ... \applications
\\\?
Package-version as the dir name is a bit more traditional, I think.
>> As to the last issue - the idea of "useful scripts"
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\
>> 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
│ │ ├───Gal
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"
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 i
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.
E
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, browse
15 matches
Mail list logo