Re: [gentoo-web-user] Java Script Libraries
Stuart Herbert [EMAIL PROTECTED] writes: Mmm ... what are you trying to achieve here? a) /usr/share/js isn't served by any of our standard webserver installs; files you place in here aren't downloadable Yes, sorry :) I already realized that it was a bad idea. b) web-based apps will expect the javascript libraries to sit in a specific location under the htdocs directory c) different web-based apps will ship different versions of javascript libraries d) sooner or later, web-based apps will ship javascript libraries with their own modifications. we already get that behaviour with apps that ship bundled PEAR packages. Yes, these libraries are more like the webapps themselves. Simply does not fit into our current concept. At least I don't see an easy solution, so I'll just leave it for now. e) The Gentoo philosophy is to remain as close to upstream as possible. Because we're a meta-distribution, and not a traditional distribution like Red Hat, the only time we try and change what UPSTREAM does is when we absolutely have to. While I agree that it is certainly easier to keep the packages as UPSTREAM bundles them, I'm not convinced that this is always a good idea. If the effort is small, I'd rather patch the package to use the standard libraries and send the patch upstream. Not only because it's simply bad programming style but also because it's easier to handle security this way. The package I'm looking at right now includes an old phpmailer library with a known DOS vulnerability. I'd rather have one place to fix a library then checking for packages that bundle the library. Regards, Gunnar -- Gunnar WrobelGentoo Developer __C_o_n_t_a_c_t__ Mail: [EMAIL PROTECTED] WWW: http://www.gunnarwrobel.de IRC: #gentoo-web at freenode.org _ pgp6Xey2NJ9Cy.pgp Description: PGP signature
RE: [gentoo-web-user] Java Script Libraries
While I agree that it is certainly easier to keep the packages as UPSTREAM bundles them, I'm not convinced that this is always a good idea. If the effort is small, I'd rather patch the package to use the standard libraries and send the patch upstream. Not only because it's simply bad programming style but also because it's easier to handle security this way. Best of luck with that ... but don't be surprised if UPSTREAM do not adopt these patches. It's not always bad programming style - it's often the only pragmatic thing to do. UPSTREAM bundle libraries because bitter experience (with poor ISP and shared hosting solutions) has taught the PHP community that if you need a third-party library and you don't bundle it, chances are that the third-party library won't be available. (The PHP and PEAR community also have to accept a lot of the blame for this state of affairs, by failing to provide an equivalent to CPAN from day one). Best regards, Stu -- gentoo-web-user@gentoo.org mailing list
RE: [gentoo-web-user] Java Script Libraries
But it is not very hard to avoid to hardwire these libs in your webapp :) This is the only thing I dislike. Mmm ... you'd be surprised, I think, about just how hard it actually is for PHP apps (and how expensive it is too). Another problem to consider is versioning of any shared libraries of code. How do you plan to address that, in a non-Gentoo-specific way? Best regards, Stu -- gentoo-web-user@gentoo.org mailing list
Re: [gentoo-web-user] Java Script Libraries
Stuart Herbert [EMAIL PROTECTED] writes:
But it is not very hard to avoid to hardwire these libs in your
webapp :) This is the only thing I dislike.
Mmm ... you'd be surprised, I think, about just how hard it actually is
for PHP apps (and how expensive it is too).
Guess I'm missing the point here. What I meant was to change stuff like this:
require_once(HOME . /thirdparty/Smarty/Smarty.class.php);
to something like this:
$include_path = ini_get('include_path');
ini_set('include_path', HOME . '/thirdparty' . SEPARATOR . $include_path);
require_once('Smarty/Smarty.class.php');
What is the negative side of such a change?
Another problem to consider is versioning of any shared libraries of
code. How do you plan to address that, in a non-Gentoo-specific way?
Where is the difference to C or Java? The recent xpdf discussion
basically touched the same issue, right? Packaging precompiled
binaries into java source packages is a common practice but has been
effictively banned by the java herd. Sometimes necessitates larger
changes in the build scripts for the app but I guess it increases
maintainability in the long run.
Where is the difference for the php libraries?
Best regards,
Gunnar
--
Gunnar WrobelGentoo Developer
__C_o_n_t_a_c_t__
Mail: [EMAIL PROTECTED]
WWW: http://www.gunnarwrobel.de
IRC: #gentoo-web at freenode.org
_
--
gentoo-web-user@gentoo.org mailing list
RE: [gentoo-web-user] Java Script Libraries
Thanks for making me aware of the issue. So let's hope for PHP5... No problem. I wish it was an idea we could implement. Alas, it's something that none of the scripting languages handle well. Even Ruby hasn't learned from the past mistakes in this area. Best regards, Stu -- gentoo-web-user@gentoo.org mailing list
Re: [gentoo-web-user] Java Script Libraries
Stuart Herbert wrote: Thanks for making me aware of the issue. So let's hope for PHP5... No problem. I wish it was an idea we could implement. Alas, it's something that none of the scripting languages handle well. Even Ruby hasn't learned from the past mistakes in this area. Ruby apps that are Gems aware handle this flawlessly. -- gentoo-web-user@gentoo.org mailing list
RE: [gentoo-web-user] Java Script Libraries
Hrm ... all the code I've seen uses: require_gem package-name with no sign of version requirements passed around. How does Gems handle the versioning in the background? Best regards, Stu -Original Message- From: Adam Sroka [mailto:[EMAIL PROTECTED] Sent: 23 February 2006 16:41 To: gentoo-web-user@lists.gentoo.org Subject: Re: [gentoo-web-user] Java Script Libraries Stuart Herbert wrote: Thanks for making me aware of the issue. So let's hope for PHP5... No problem. I wish it was an idea we could implement. Alas, it's something that none of the scripting languages handle well. Even Ruby hasn't learned from the past mistakes in this area. Ruby apps that are Gems aware handle this flawlessly. -- gentoo-web-user@gentoo.org mailing list -- gentoo-web-user@gentoo.org mailing list
Re: [gentoo-web-user] Java Script Libraries
Stuart Herbert wrote: Hrm ... all the code I've seen uses: require_gem package-name with no sign of version requirements passed around. How does Gems handle the versioning in the background? Best regards, Stu That code is implicitly saying use the latest version of package-name. However, Gems also lets you say: require_gem 'package-name', '= 1.1.5' One of the most useful things you can do is say: '~ 1.1' This means, use the version closest to 1.1, but I don't care which minor revision you use. This will allow you to pick up new minor revisions that contain, for instance, a security patch, but not major revisions that might change the API. For more info see here: http://docs.rubygems.org/read/chapter/16 Another thing that is great about Gems is that you can stand up a gem server and serve your own versions of any required libraries. All a user would have to do is point at your gem server, and they could use your version. This is analogous to having your own rsync server. -- gentoo-web-user@gentoo.org mailing list
