coapp-developers team mailing list archive

[Elizabeth M Smith <emsmith@xxxxxxxxxxxxxxxxxxxxxxx>]

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 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.

Yeah, I think so too - you don't edit ZF and PEAR , you just use them 
;)  As long as you can do multiple versions of them sounds good.

> 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.
I don't think it's really a "web library" if you have to edit it.  If 
you have to change files to make it run, it's an application.  And the 
platform neutral thing has ALREADY bit me in the butt (stupid (x86) at 
the end of program files) - maybe we just need to always put the neutral 
stuff in just plain program files.... sigh
> 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.
I dunno - some things unix doesn't get right in my opinion.  Any reason 
not do to <package>/<package-version> - so you have wordpress with your 
15 million versions inside named wordpress-1.5 and wordpress-2.0 etc etc 
etc.

I know some things DO follow this pattern to some extent (stuff in the 
gtk stack do this with the includes directories - so you have 
/gtk/gtk-2.0 etc)

Not really that important - just something to ponder.
> Arglegarble.
>
> g

hehe - I just want to play with code... really.

Thanks,
Elizabeth M Smith