Forum OpenACS Development: best place for images?

Collapse
Posted by Rafael Calvo on
Where is the best place to put images and how do you do it?.

I am trying to add some images to default-master.adp.Should the images
be in /web/openacs-4/www/images? if they are designed for a particular
package should they go in: /web/openacs-4/packages/packgX/www/images?
I haven't seen any packages with default images...

Collapse
Posted by Rafael Calvo on
This might have sounded like a very silly question (and it was) but was based on a stupid bug I had. better go to sleep.
Collapse
Posted by Jun Yamog on
Hi Rafael,

Despite that OpenACS 4.x is not released yet I am already using it.  Here is so far what I can share based from experience.

I put common images in www/images if 2 or more package use it or the image is used by static content.  You need to put it somewhere common where in you can put in your adp the correct URL.  You can mount any package at any URL, this is an advantage also a disadvantage in linking images to it.

I put images on packages/[package key]/www/images when only this package needs to access the image.  Such images I use for example is a ticket tracker icons, etc.  This way the use of relative href will always work.

I think in your case it would be better to put in www/images since its on a template which will be used in different URLs.  I have also learned not to touch the www/default-template.  I made my own template in /templates.  On each subsite you can set the parameters on the default template.  The main site is a subsite too so you can do this.  Although my installation I created another subsite for my site, leaving everything to be still www/default-template.  And everthing in my site to templated.  See skins document on a demo of this.

You can also put your images in Content Repository.  I have not yet done this.  Although much of my content is a little bit ready once OpenACS 4.0 has a release tree in their code I will put my content on CR.  Anybody who has done this please explain.  I have some idea on it and small tcl code that puts content and gets content out.  Although it would be great to have someone tell how to best do it.

Is there a way for me to contribute on such a faq or best practices doc?  Make a thread first in the bboard like "what is the best way to run multiple acs sites".  After a period of time the best practices are then compiled to a FAQ.  It will be called something like "Best Practices in OpenACS".  Topics ranging from Sysadmin stuff like installation to developer stuff like what is the best way to extend OpenACS 4.x

Collapse
Posted by Walter McGinnis on
The photo-album package uses a www/graphics directory for icon image files to avoid confusion with the images content_type which comes with  and is stored in the CR.
Collapse
Posted by Arjun Sanyal on
I'd like to standarize on a site-wide images directory for oacs 4.6.

I've just converted some nice icons from the gnome project that
we'er going to be using in forums, attachments, and maybe elsewhere. Package authors/fixers could use these for a more standard inter-package look.

I also like walter's suggestion to use [pageroot]/www/graphics instead of /images to make the distinction between images in the
filesystem and in the CR.

How 'bout it?

Collapse
Posted by David Kuczek on
I really like Musea's general-images module for 3.2.5 that comes with their lightweight cms system... Such a thing will be valuable for 4.6! And I really support the use of icons through all packages. It makes oacs look more professional out of the box!
Collapse
Posted by Roberto Mello on
Arjun, I think that'd be great! Reuse, consistency and better looks.
Collapse
Posted by Andrew Grumet on
Arjun, I'm not sure I follow your suggestion to use "[pageroot]/www/graphics" since the AOLserver pageroot typically contains the www part.

Either way, I propose

${aolserver-pageroot}/graphics/${package-key}/
${aolserver-pageroot}/graphics/shared/
with the latter being used for shared graphics.

Putting all the graphics under the same directory makes life a lot easier when you want to set up special rules for image files (say, in a hardware switch in front of your servers). Putting them under the pageroot in particular has the nice effect of not requiring the site-node machinery. This will help if we decide one day to put a little hook into the request processor that says "if the URL starts with /graphics, just serve the file".

Doing things this way will mean some changes to APM, which wants to put all files associated with a package under ${serverroot}/packages/${package-key}. But I think it's the right solution.

Collapse
Posted by Arjun Sanyal on
Swell. If no one objects I'll commit the /www/graphics folder to the 4.6 tree and the icons I converted from ximian/gnome tommorow.

The icons (forward, reply, search, and attach) were 24x24 px .png files that I hand converted and cleaned up into .gif in the gimp.

Tip: if you want to convert .png to .gif, don't use
ImageMagick's so called "convert" tool since it makes the partially opaque (.gif dosen't have partial opacity) parts of the .png image into a nasty black when converted to .gif. the gimp converts these areas to fully transparent.

Collapse
Posted by Lars Pind on
Arjun,

Another possible place is packages/acs-subsite/www/shared/ where the 1pixel script already lives.

Graphics that belong to a package should live in the package directory. Graphics that are intended to be shared could either live in acs-subsite/www/shared or somewhere under the pageroot.

/Lars

Collapse
Posted by Andrew Grumet on
Graphics that belong to a package should live in the package directory. Graphics that are intended to be shared could either live in acs-subsite/www/shared or somewhere under the pageroot.

I agree with the sentiment, for sure. But I also work on a site where we use a second, non-ACS instance of AOLserver with fastpath turned on for serving images. We use a hardware switch to redirect everything that matches /images/* to this server. And it's really fast.

The problem with images in separate directories by package is that you now have to program all of this knowledge about separate directories into your hardware switch.

I guess one alternative is to set up a bunch of symlinks.

Other ideas?

Collapse
Posted by Lars Pind on
Ah, so there are really two issues:

One if the issue of distribution, in which having everything stay together in one package directory/package file is really nice.

The other is production, in which there are other concerns. Hm. I guess the request-processor could be simplified a great deal if it could only maintain a large part of the site map as files/directories/symlinks in the file system.

Oh, well, a thought for some other day.

/Lars

Collapse
Posted by Andrew Grumet on
I guess another thing to consider on the directories issue is: RPMs.  Running "rpm -qf" on a few programs, I see that it is common to place files in multiple directories (/usr/lib, /usr/bin, /usr/share/man etc) as opposed to a package-specific directory.  Does this tend to make life better or worse for linux users and administrators?  I don't actually know, but am curious if anyone is familiar with such discussions in the linux community.
Collapse
Posted by John Mileham on
Has anybody given any thought to the scenario of using the host-node map?  Putting the images inside acs-subsite would be pretty much a requirement in order to make use of icons in the context of a subsite mounted at its own virtual root.  Or should there be a truly shared folder at the like [acs_root_dir]/shared (not to be confused with pageroot) that is mounted at the root of every possible virtual host?
Collapse
Posted by Roberto Mello on
Arjun, I'm puzzled as to why you are converting these to .gif. Shouldn't we be moving away from the patent-encumbered gif?. png has very good support in browsers, from 4.0 and above.
Collapse
Posted by John Mileham on
If I'm not mistaken, a number of plugins on various platforms take it upon themselves to display PNGs for browsers (even >=4.x), with poor results (loss of the ability to do partial transparency, and in some situations, they result in broken plugin prompts).  I wish PNGs were safe, but I'm still not sure that they meet the lowest common denominator client that OACS has been so happy to support until now.

Of course if more people took the plunge and started using PNGs, there'd be better support out there... if you're not part of the solution, you're part of the problem.

Short version: I'm torn, but gifs are safe, if not entirely legit or quite as capable as pngs.

Collapse
Posted by Don Baccus on
Hmmm one graphics directory to bind them all ...

Shouldn't we be making this a subsite-level param rather than assume a global location?  After all if I build a Big Blue subsite and another Rad Red subsite I may want different icons to complement my cool color schemes.

Collapse
Posted by Andrew Grumet on
After thinking about it further, if piling everything into one directory is just too gross, image caching could probably still be accomplished by putting a squid-cache in front of OpenACS.  In the case I mention above, that would have been more work (the sysadmins already had a switch in place, but didn't have squid-cache installed) but certainly possible.

Or maybe an enterprising C programmer wants to see if anything creative can be done with fastpath (which, incidentally, won't run on OpenACS systems because you can't register more than one proc on "/").

Collapse
Posted by Don Baccus on
How about a "/images" directory that includes a .vuh file that grabs the image from the right (in-a-package) place?  Your cache box would see a simple URL and be tricked into doing the right thing after the image was first delivered.  This isn't much different than putting out trick URLs that Akamai understands (which I got to do for Greenpeace, fun!)

In other words ... in your environment you can hack code to do what you need even if the files are placed in a more package-friendly place.