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, should we have a "Program Files\Shared" type of directory? Similar to the /usr/share on UNIX? Or Libraries? For non-web apps, I had specified a place for common things ( see http://coapp.org/Blueprints/Packages/1._Common_Package_Blueprint ) The pattern works pretty good for shared libraries or components that are designed to be immutable. Zend Frameworks and PEAR libraries really fall into that category. I'd also argue shared web libraries that are not intended to be modified should install in Program Files\<publisher>\<product> like everything else. The only down side is that it's less discoverable, nor is it likely 32-bit / 64-bit specific. (and MS in their infinite wisdom didn't give us a platform-neutral program files directory. That's gonna bite us 10-20 years from now.) I think web libraries which are likely to be subject to some editing/modification should still go in inetpub. Hmmm. Still gonna have to think some more. Oh, and I was going to agree with <package>\<version> ... it means less repetition, but it's inconsistent with the layout for docs & include folder in the common package blueprint, which I patterned off of unix's way of doing it. Arglegarble. g 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 12:34 PM To: 'Elizabeth M Smith'; Garrett Serack Cc: [email protected] Subject: RE: [Coapp-developers] Another kind of package. 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 conversation that's been going on for a while. I'm flexible though. I agree it should be chronological on a forum though. I see too many web sites that post comments backwards as newest first so you have to get to the last page and read backwards. Maybe distribution lists fall into this category. I think the package-version is just normal because that's what you always get when you untar the package file. For libraries, should we have a "Program Files\Shared" type of directory? Similar to the /usr/share on UNIX? Or Libraries? Trev. From: coapp-developers-bounces+trevor=dennis-it....@lists.launchpad.net [mailto:coapp-developers-bounces+trevor=dennis-it....@lists.launchpad.net] On Behalf Of Elizabeth M Smith Sent: Tuesday, April 06, 2010 1:13 PM To: Garrett Serack Cc: [email protected] Subject: Re: [Coapp-developers] Another kind of package. 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/<vendor>/<package>/<version> ...\applications\<vendor>\<package-version> or ... \applications \<vendor>\<package>\<version>? Package-version as the dir name is a bit more traditional, I think. Don't really think it matters - but personally it IS nice to have all your versions in one directory ;) just a nicer way to look at them in my mind >> To further complicate things there is the idea of things in the PHP that >> script libraries like PEAR and Zend Framework... Ah. Yes.Hmmm. How about ...\libraries\<vendor>\<package-version> for shared 'web libraries' like PEAR. This makes the tree (and increases the necessity for \sites , \applications and \libraries) inetpub ├───applications │ ├───CoApp │ │ ├───Gallery-2.0.7 │ │ └───phpBB-3.0.2 │ └───WordPress │ ├───WordPress-4.3.6 │ └───WordPress-4.3.7 ├───libraries │ ├───Adodb │ │ └───AdoDB-2.5.6 │ └───Zend │ └───ZendFrameworks-2.4.1 └───sites ├───bar.com ├───baz.org └───foo.com Except then you run into things that AREN'T web apps being written in a web language using a library. PHP-GTK and PyGTK scripts, pyrus/pear packaging code, phpunit test suites - they all want to use libraries that aren't necessarily confined to web space. All these dynamic languages make traditional organization pretty hard ;) Thanks, Elizabeth M Smith
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
