Re: Gallery 3.1 - auto-upgrading, directory structure
Bharat Mediratta <[email protected]> Sat, 13 Apr 2013 11:49:45 -0700
| Newsgroups | gmane.comp.web.gallery.devel |
|---|---|
| Message-ID | <CAESa+_mmfNaQLjqnt=NvrumPPiX_YU57ks+f8VSNvYL2aTT10g@mail.gmail.com> |
--===============0947230007662716492== Content-Type: multipart/alternative; boundary=047d7bdca69c25446e04da427e3f --047d7bdca69c25446e04da427e3f Content-Type: text/plain; charset=ISO-8859-1 I think our script should abort if it notices a .git directory. On Fri, Apr 12, 2013 at 11:00 PM, Tim Almdal <[email protected]> wrote: > My thoughts... er question? > 2b) How do you handle the case where people are tracking trunk? How do I > do an inplace upgrade from 3.0? > > > ----- Original Message ----- > From: "Bharat Mediratta" <[email protected]> > To: "Shad Laws" <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> > Cc: "gallery-devel" <[email protected]> > Sent: Friday, April 12, 2013 3:44:00 PM > Subject: Re: [Gallery-devel] Gallery 3.1 - auto-upgrading, directory > structure > > > > > > > Gallery 2 has a means of doing this. It worked, but was heavy and ran > into a lot of issues around things like: > > > 1) API compatibility across major/minor boundaries > 2) Filesystem permissions > 3) Dealing with local code modifications made by the user > 4) Added complexity in the code to deal with multiple possible locations > of modules > > > I propose that we do the following: > 1) Leave our structure exactly the way it is > 2) Push out a really simple PHP file that does the following > 2a) check filesystem permissions everywhere and make sure that the webapp > can update everything > 2b) download a tarball > 2c) unpack it on top of all the existing code (and maybe delete extra > files we know to be problems - this saves us the trouble of having to tell > users to blow away all their old stuff) > 2d) runs "system php upgrader.php" or something equally API-simple > > > This is simple and fast. We can write the code whenever we want. It's > not guaranteed to be super reliable and we can add tests, etc to try to > verify the environment before we do anything radical. It should also be > very little code. > > > thoughts? > > > On Fri, Apr 12, 2013 at 11:44 AM, Shad Laws < shad-xpYdmXCiSuZWk0Htik3J/[email protected] > wrote: > > > Hey everyone, > > I feel rather strongly that it'd be a *big* boon to Gallery if we made > v3.1+ self-upgrading. Of course, this is a big undertaking, but I think > it'd be well worth it. > > To me, it seems that there are three parts to the problem: > - infrastructure on www.galleryproject.org > - self-upgrading code > - an application structure that makes it easier to self-upgrade without > destroying user mods > > I've been thinking a lot about the last item, and I feel like it should be > the first to be tackled. Below are my current thoughts on it... > > ---- > > OVERVIEW > > Kohana 3 is pretty agnostic when it comes to module/theme locations. > APPPATH and SYSPATH are important, but MODPATH really isn't. In fact, > grepping for MODPATH will find one match in Debug::path() which can (and > should!) be easily overriden. However, there's a big boon to having > *everything* (including SYSPATH and APPPATH) use the same module structure. > > We leveraged these facts some in Gallery 3.0.x (e.g. MODPATH vs. > THEMEPATH), but I say we should do so more in Gallery 3.1.x. > > So, here's my new idea. There are eight main subdirectories, each with a > different purpose. > > First, the installer. This should never be modified by either the end > user or upgraders. This is where we should put our core upgrade code. > - installer > > Next, the three "core" directories. These should never be modified by the > end user. A gallery-wide upgrade simply deletes and replaces these. > - core: application, system, and all third-party modules; no module.infofiles here > - modules-gallery: all other modules gallery ships with > - themes-gallery: wind, admin_wind, and lib > > Then, the two "contrib" directories. The end user may need to *install* > these, but should never *modify* them. A contrib module installer/updater > can operate by deleting/rebuilding subdirs here. These are shipped only > with README.md files. > - modules-contrib > - themes-contrib > > Then, the two "site-specific" directories. This is where all config, > custom code, and other tweaks should go. The end user is highly encouraged > to modify stuff here :-). > - bin: shipped with only README.md and .htaccess files > - site: all custom code goes here; see more info below > > Finally, the var directory. This is where all of our data goes. The end > user shouldn't need to modify things directly here... and neither should > Gallery upgraders. > - var > > Once we do this, we can remove every instance of MODPATH and > Gallery::find_file() in the core code and replace it with > Kohana::find_file(). > > ---- > > DETAILS - MAIN > > Here's a sketch of what Gallery would look like. For brevity, I've > omitted all files and subdirs with the exception of vendor. > > gallery > |-- bin > |-- core > | |-- application [Note 1] > | | `-- vendor > | | `-- htmlpurifier > | |-- cache > | |-- database > | |-- formo > | |-- orm > | |-- image > | |-- pagination > | |-- unittest > | `-- system > |-- installer > |-- modules-contrib > |-- modules-gallery > | |-- akismet > | |-- comment > | |-- exif > | | `-- vendor > | | `-- exifer > | |-- g2_import > | |-- gallery [Note 2] > | | `-- vendor > | | |-- jquery-file-upload [Note 3] > | | |-- mediaelementjs > | | `-- joomla > | |-- gallery_unittest > | |-- image_block > | |-- info > | |-- notification > | |-- organize > | |-- recaptcha > | |-- rest > | |-- rss > | |-- search > | |-- server_add > | |-- slideshow > | |-- tag > | |-- user > | |-- watermark > |-- site [Note 4] > |-- themes-contrib > |-- themes-gallery > | |-- admin_wind > | |-- lib [Note 5] > | `-- wind > `-- var [Note 6] > |-- albums > |-- backups [Note 7] > |-- caches [Note 8] > |-- logs > |-- modules > |-- resizes > |-- thumbs > |-- tmp > `-- uploads > > Note 1: application includes bootstrap, purifier, and > load_modules/load_themes code. This stuff can never be overridden. > Note 2: gallery includes code to swap the active theme for admin and/or > override if needed. > Note 3: jquery-file-upload will replace uploadify/swfobject. > Note 4: site details are below. > Note 5: lib details are below. > Note 6: var root directory is empty, and the database config has been > moved to site. > Note 7: should use this for backup SQL dumps :-) > Note 8: cache is new for Kohana 3 caches. > > ---- > > DETAILS - SITE AND LIB > > My goal is to encourage end users to use the site directory for *all* > tweaks of any kind. It's full of a bunch of templates, which they can > modify (and then remove .tmpl) to change gallery without actually touching > the core or contrib files. > > site > |-- README.md (tells how to use this directory) > |-- init.tmpl (this takes the place of the old local.php file) > |-- assets > | |-- apple-touch-icon.png.tmpl > | |-- favicon.ico.tmpl > | |-- logo.png.tmpl > | |-- site.css.tmpl (custom css, which is loaded last, goes here) > | `-- site.js.tmpl (custom js, which is loaded last, goes here) > |-- classes > | |-- Example.php.tmpl (tells how to override a class instead of > modifying it directly) > | `-- Hook (each template includes a list of possible > functions) > | |-- Rest > | | `-- Site.php.tmpl > | |-- SiteEvent.php.tmpl > | |-- SiteRss.php.tmpl > | |-- SiteTask.php.tmpl > | `-- SiteTheme.php.tmpl > `-- config > `-- database.php (this was var/database.php in 3.0.x) > > Also, I'd like to move the lib directory around a bit to make it like the > other modules, remove the things that aren't specific to the theme > (uploader and movie player), and then put it as a theme subdir. I used a > couple wildcards for brevity below. The end result would look like this: > > lib > |-- assets > | |-- apple-touch-icon.png > | |-- favicon.ico > | |-- logo.png > | |-- gallery*.js > `-- vendor > |-- jquery*.js > |-- json*.js > |-- superfish > `-- yui > > ---- > > MODULE ORDER > > Our complete module order would look like this: > > core/application (APPPATH req'd by Kohana) > modules-gallery/gallery_unittest (if TEST_MODE) > core/unittest (if TEST_MODE) > site > [active theme] > themes-gallery/lib > [active modules...] > [active identity provider] > modules-gallery/gallery > core/pagination > core/formo > core/image > core/cache > core/orm > core/database > core/system (SYSPATH req'd by Kohana) > > Additionally, during bootstrap and configuration, we load a few modules > before the whole list: > > core/application (APPPATH req'd by Kohana) > site (allows init to be run) > modules-gallery/gallery > core/cache > core/orm > core/database > core/system (SYSPATH req'd by Kohana) > > ---- > > Whew - that took awhile to write up! So... whaddayathink? > > Thanks for readin'! > > Take care, > Shad > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > __[ g a l l e r y - d e v e l ]_________________________ > > [ list info/archive --> http://gallery.sf.net/lists.php ] > [ gallery info/FAQ/download --> http://gallery.sf.net ] > > > > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > __[ g a l l e r y - d e v e l ]_________________________ > > [ list info/archive --> http://gallery.sf.net/lists.php ] > [ gallery info/FAQ/download --> http://gallery.sf.net ] > > --047d7bdca69c25446e04da427e3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div style>I think our script should abort if it notic= es a .git directory.</div></div><div class=3D"gmail_extra"><br><br><div cla= ss=3D"gmail_quote">On Fri, Apr 12, 2013 at 11:00 PM, Tim Almdal <span dir= =3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">tnalmdal= @shaw.ca</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">My thoughts... er question?<br> 2b) How do you handle the case where people are tracking trunk? How do I do= an inplace upgrade from 3.0?<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> <br> ----- Original Message -----<br> From: "Bharat Mediratta" <<a href=3D"mailto:[email protected]= ">[email protected]</a>><br> To: "Shad Laws" <<a href=3D"mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]">shad@sha= dlaws.com</a>><br> Cc: "gallery-devel" <<a href=3D"mailto:[email protected]= rceforge.net">[email protected]</a>><br> Sent: Friday, April 12, 2013 3:44:00 PM<br> Subject: Re: [Gallery-devel] Gallery 3.1 - auto-upgrading, =A0 =A0 =A0direc= tory structure<br> <br> <br> <br> <br> <br> <br> Gallery 2 has a means of doing this. =A0It worked, but was heavy and ran in= to a lot of issues around things like:<br> <br> <br> 1) API compatibility across major/minor boundaries=A0<br> 2) Filesystem permissions<br> 3) Dealing with local code modifications made by the user<br> 4) Added complexity in the code to deal with multiple possible locations of= modules<br> <br> <br> I propose that we do the following:<br> 1) Leave our structure exactly the way it is<br> 2) Push out a really simple PHP file that does the following<br> 2a) check filesystem permissions everywhere and make sure that the webapp c= an update everything<br> 2b) download a tarball<br> 2c) unpack it on top of all the existing code (and maybe delete extra files= we know to be problems - this saves us the trouble of having to tell users= to blow away all their old stuff)<br> 2d) runs "system php upgrader.php" or something equally API-simpl= e<br> <br> <br> This is simple and fast. =A0We can write the code whenever we want. =A0It&#= 39;s not guaranteed to be super reliable and we can add tests, etc to try t= o verify the environment before we do anything radical. =A0It should also b= e very little code.<br> <br> <br> thoughts?<br> <br> <br> On Fri, Apr 12, 2013 at 11:44 AM, Shad Laws < <a href=3D"mailto:shad@sha= dlaws.com">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a> > wrote:<br> <br> <br> Hey everyone,<br> <br> I feel rather strongly that it'd be a *big* boon to Gallery if we made = v3.1+ self-upgrading. =A0Of course, this is a big undertaking, but I think = it'd be well worth it.<br> <br> To me, it seems that there are three parts to the problem:<br> - infrastructure on <a href=3D"http://www.galleryproject.org" target=3D"_bl= ank">www.galleryproject.org</a><br> - self-upgrading code<br> - an application structure that makes it easier to self-upgrade without des= troying user mods<br> <br> I've been thinking a lot about the last item, and I feel like it should= be the first to be tackled. =A0Below are my current thoughts on it...<br> <br> ----<br> <br> OVERVIEW<br> <br> Kohana 3 is pretty agnostic when it comes to module/theme locations. =A0APP= PATH and SYSPATH are important, but MODPATH really isn't. =A0In fact, g= repping for MODPATH will find one match in Debug::path() which can (and sho= uld!) be easily overriden. =A0However, there's a big boon to having *ev= erything* (including SYSPATH and APPPATH) use the same module structure.<br= > <br> We leveraged these facts some in Gallery 3.0.x (e.g. MODPATH vs. THEMEPATH)= , but I say we should do so more in Gallery 3.1.x.<br> <br> So, here's my new idea. =A0There are eight main subdirectories, each wi= th a different purpose.<br> <br> First, the installer. =A0This should never be modified by either the end us= er or upgraders. =A0This is where we should put our core upgrade code.<br> - installer<br> <br> Next, the three "core" directories. =A0These should never be modi= fied by the end user. =A0A gallery-wide upgrade simply deletes and replaces= these.<br> - core: application, system, and all third-party modules; no <a href=3D"htt= p://module.info" target=3D"_blank">module.info</a> files here<br> - modules-gallery: all other modules gallery ships with<br> - themes-gallery: wind, admin_wind, and lib<br> <br> Then, the two "contrib" directories. =A0The end user may need to = *install* these, but should never *modify* them. =A0A contrib module instal= ler/updater can operate by deleting/rebuilding subdirs here. =A0These are s= hipped only with README.md files.<br> - modules-contrib<br> - themes-contrib<br> <br> Then, the two "site-specific" directories. =A0This is where all c= onfig, custom code, and other tweaks should go. =A0The end user is highly e= ncouraged to modify stuff here :-).<br> - bin: shipped with only README.md and .htaccess files<br> - site: all custom code goes here; see more info below<br> <br> Finally, the var directory. =A0This is where all of our data goes. =A0The e= nd user shouldn't need to modify things directly here... and neither sh= ould Gallery upgraders.<br> - var<br> <br> Once we do this, we can remove every instance of MODPATH and Gallery::find_= file() in the core code and replace it with Kohana::find_file().<br> <br> ----<br> <br> DETAILS - MAIN<br> <br> Here's a sketch of what Gallery would look like. =A0For brevity, I'= ve omitted all files and subdirs with the exception of vendor.<br> <br> gallery<br> |-- bin<br> |-- core<br> | =A0 |-- application =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Note 1]<br> | =A0 | =A0 `-- vendor<br> | =A0 | =A0 =A0 =A0 `-- htmlpurifier<br> | =A0 |-- cache<br> | =A0 |-- database<br> | =A0 |-- formo<br> | =A0 |-- orm<br> | =A0 |-- image<br> | =A0 |-- pagination<br> | =A0 |-- unittest<br> | =A0 `-- system<br> |-- installer<br> |-- modules-contrib<br> |-- modules-gallery<br> | =A0 |-- akismet<br> | =A0 |-- comment<br> | =A0 |-- exif<br> | =A0 | =A0 `-- vendor<br> | =A0 | =A0 =A0 =A0 `-- exifer<br> | =A0 |-- g2_import<br> | =A0 |-- gallery =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Note 2]<br> | =A0 | =A0 `-- vendor<br> | =A0 | =A0 =A0 =A0 |-- jquery-file-upload =A0[Note 3]<br> | =A0 | =A0 =A0 =A0 |-- mediaelementjs<br> | =A0 | =A0 =A0 =A0 `-- joomla<br> | =A0 |-- gallery_unittest<br> | =A0 |-- image_block<br> | =A0 |-- info<br> | =A0 |-- notification<br> | =A0 |-- organize<br> | =A0 |-- recaptcha<br> | =A0 |-- rest<br> | =A0 |-- rss<br> | =A0 |-- search<br> | =A0 |-- server_add<br> | =A0 |-- slideshow<br> | =A0 |-- tag<br> | =A0 |-- user<br> | =A0 |-- watermark<br> |-- site =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Note 4]<br= > |-- themes-contrib<br> |-- themes-gallery<br> | =A0 |-- admin_wind<br> | =A0 |-- lib =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Note 5]<br> | =A0 `-- wind<br> `-- var =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Note 6]<br= > =A0 =A0 |-- albums<br> =A0 =A0 |-- backups =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [Note 7]<br> =A0 =A0 |-- caches =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[Note 8]<br> =A0 =A0 |-- logs<br> =A0 =A0 |-- modules<br> =A0 =A0 |-- resizes<br> =A0 =A0 |-- thumbs<br> =A0 =A0 |-- tmp<br> =A0 =A0 `-- uploads<br> <br> Note 1: application includes bootstrap, purifier, and load_modules/load_the= mes code. =A0This stuff can never be overridden.<br> Note 2: gallery includes code to swap the active theme for admin and/or ove= rride if needed.<br> Note 3: jquery-file-upload will replace uploadify/swfobject.<br> Note 4: site details are below.<br> Note 5: lib details are below.<br> Note 6: var root directory is empty, and the database config has been moved= to site.<br> Note 7: should use this for backup SQL dumps :-)<br> Note 8: cache is new for Kohana 3 caches.<br> <br> ----<br> <br> DETAILS - SITE AND LIB<br> <br> My goal is to encourage end users to use the site directory for *all* tweak= s of any kind. =A0It's full of a bunch of templates, which they can mod= ify (and then remove .tmpl) to change gallery without actually touching the= core or contrib files.<br> <br> site<br> |-- README.md =A0 (tells how to use this directory)<br> |-- init.tmpl =A0 (this takes the place of the old local.php file)<br> |-- assets<br> | =A0 |-- apple-touch-icon.png.tmpl<br> | =A0 |-- favicon.ico.tmpl<br> | =A0 |-- logo.png.tmpl<br> | =A0 |-- site.css.tmpl =A0 =A0 (custom css, which is loaded last, goes her= e)<br> | =A0 `-- site.js.tmpl =A0 =A0 =A0(custom js, which is loaded last, goes he= re)<br> |-- classes<br> | =A0 |-- Example.php.tmpl =A0(tells how to override a class instead of mod= ifying it directly)<br> | =A0 `-- Hook =A0 =A0 =A0 =A0 =A0 =A0 =A0(each template includes a list of= possible functions)<br> | =A0 =A0 =A0 |-- Rest<br> | =A0 =A0 =A0 | =A0 `-- Site.php.tmpl<br> | =A0 =A0 =A0 |-- SiteEvent.php.tmpl<br> | =A0 =A0 =A0 |-- SiteRss.php.tmpl<br> | =A0 =A0 =A0 |-- SiteTask.php.tmpl<br> | =A0 =A0 =A0 `-- SiteTheme.php.tmpl<br> `-- config<br> =A0 =A0 `-- database.php =A0 =A0 =A0(this was var/database.php in 3.0.x)<br= > <br> Also, I'd like to move the lib directory around a bit to make it like t= he other modules, remove the things that aren't specific to the theme (= uploader and movie player), and then put it as a theme subdir. =A0I used a = couple wildcards for brevity below. =A0The end result would look like this:= <br> <br> lib<br> |-- assets<br> | =A0 |-- apple-touch-icon.png<br> | =A0 |-- favicon.ico<br> | =A0 |-- logo.png<br> | =A0 |-- gallery*.js<br> `-- vendor<br> =A0 =A0 |-- jquery*.js<br> =A0 =A0 |-- json*.js<br> =A0 =A0 |-- superfish<br> =A0 =A0 `-- yui<br> <br> ----<br> <br> MODULE ORDER<br> <br> Our complete module order would look like this:<br> <br> core/application (APPPATH req'd by Kohana)<br> modules-gallery/gallery_unittest (if TEST_MODE)<br> core/unittest (if TEST_MODE)<br> site<br> [active theme]<br> themes-gallery/lib<br> [active modules...]<br> [active identity provider]<br> modules-gallery/gallery<br> core/pagination<br> core/formo<br> core/image<br> core/cache<br> core/orm<br> core/database<br> core/system (SYSPATH req'd by Kohana)<br> <br> Additionally, during bootstrap and configuration, we load a few modules bef= ore the whole list:<br> <br> core/application (APPPATH req'd by Kohana)<br> site (allows init to be run)<br> modules-gallery/gallery<br> core/cache<br> core/orm<br> core/database<br> core/system (SYSPATH req'd by Kohana)<br> <br> ----<br> <br> Whew - that took awhile to write up! =A0So... whaddayathink?<br> <br> Thanks for readin'!<br> <br> Take care,<br> Shad<br> ---------------------------------------------------------------------------= ---<br> Precog is a next-generation analytics platform capable of advanced<br> analytics on semi-structured data. The platform includes APIs for building<= br> apps and a phenomenal toolset for data science. Developers can use<br> our toolset for easy data analysis & visualization. Get a free account!= <br> <a href=3D"http://www2.precog.com/precogplatform/slashdotnewsletter" target= =3D"_blank">http://www2.precog.com/precogplatform/slashdotnewsletter</a><br= > __[ g a l l e r y - d e v e l ]_________________________<br> <br> [ list info/archive --> <a href=3D"http://gallery.sf.net/lists.php" targ= et=3D"_blank">http://gallery.sf.net/lists.php</a> ]<br> [ gallery info/FAQ/download --> <a href=3D"http://gallery.sf.net" target= =3D"_blank">http://gallery.sf.net</a> ]<br> <br> <br> <br> <br> ---------------------------------------------------------------------------= ---<br> Precog is a next-generation analytics platform capable of advanced<br> analytics on semi-structured data. The platform includes APIs for building<= br> apps and a phenomenal toolset for data science. Developers can use<br> our toolset for easy data analysis & visualization. Get a free account!= <br> <a href=3D"http://www2.precog.com/precogplatform/slashdotnewsletter" target= =3D"_blank">http://www2.precog.com/precogplatform/slashdotnewsletter</a><br= > __[ g a l l e r y - d e v e l ]_________________________<br> <br> [ list info/archive --> <a href=3D"http://gallery.sf.net/lists.php" targ= et=3D"_blank">http://gallery.sf.net/lists.php</a> ]<br> [ gallery info/FAQ/download --> <a href=3D"http://gallery.sf.net" target= =3D"_blank">http://gallery.sf.net</a> ]<br> <br> </div></div></blockquote></div><br></div> --047d7bdca69c25446e04da427e3f-- --===============0947230007662716492== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter --===============0947230007662716492== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline __[ g a l l e r y - d e v e l ]_________________________ [ list info/archive --> http://gallery.sf.net/lists.php ] [ gallery info/FAQ/download --> http://gallery.sf.net ] --===============0947230007662716492==--