ids-devel — IDS developers use this list

Re: [Ids-devel] album_image (cont.)

[John M. <mo...@mu...>]

As you might have gathered, testing is not my forte...

Replace line 656 with this instead:

		$imageForPreview = openAlbumImage("$imagepreviewdir/");
		if ($imageForPreview ne '') {
			$imageForPreview = $ppath . "albums" . $imageForPreview;
		}

The cookie bug is also fixed.

You can get IDS 0.711b1 here:
http://arwen.hn.org/~john/ids-devel/

John

On Monday, June 18, 2001, at 09:45 AM, John Moose wrote:
> Argh.
>
> It looks like this bug can be fixed by changing line 656 in 
> idsShared.pm from:
>
> $imageForPreview = openAlbumImage("$imagepreviewdir/");
>
> to:
>
> $imageForPreview = $ppath."albums" . 
> openAlbumImage("$imagepreviewdir/");
>
> I found another bug in the way the "path" variable is set in the 
> cookie. I'm fixing that now.
>
> What do you think? 0.711?
>
> John
>
>
> On Monday, June 18, 2001, at 03:39 AM, Ashley M. Kirchner wrote:
>>
>>     I take that back.  Even if the image file does exist, and
>> album_image.txt contains the correct path and all, IDS still picks a
>> random image when generating a (new) album thumbnail.  Simple test:
>>
>>     Pick image, set as album icon.  Verify that album_image.txt has the
>> correct path and image file in it.  Delete the <theme>.png file that 
>> was
>> just generated from that process.  Reload the page and a) the thumbnail
>> is randomly selected, and b) album_image.txt gets over written with the
>> new image path.
>>
>>     I woulda thunk album_image.txt, containing the correct path, and
>> valid image file, would be re-used in (re)generating album thumbnails,
>> and not over written with a new random image.
>>
>> --
>> H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
>>   +--------------------------------------------------------------------
>>   Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
>>   Director of Internet Operations / SysAdmin    .     800.441.3873 x130
>>   Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave, #6
>>   http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.
>>
>>
>>
>> _______________________________________________
>> IDS-devel mailing list
>> IDS...@li...
>> http://lists.sourceforge.net/lists/listinfo/ids-devel
>
>
> _______________________________________________
> IDS-devel mailing list
> IDS...@li...
> http://lists.sourceforge.net/lists/listinfo/ids-devel

Re: [Ids-devel] album_image (cont.)

[John M. <mo...@mu...>]

Argh.

It looks like this bug can be fixed by changing line 656 in idsShared.pm 
from:

$imageForPreview = openAlbumImage("$imagepreviewdir/");

to:

$imageForPreview = $ppath."albums" . openAlbumImage("$imagepreviewdir/");

I found another bug in the way the "path" variable is set in the cookie. 
I'm fixing that now.

What do you think? 0.711?

John


On Monday, June 18, 2001, at 03:39 AM, Ashley M. Kirchner wrote:
>
>     I take that back.  Even if the image file does exist, and
> album_image.txt contains the correct path and all, IDS still picks a
> random image when generating a (new) album thumbnail.  Simple test:
>
>     Pick image, set as album icon.  Verify that album_image.txt has the
> correct path and image file in it.  Delete the <theme>.png file that was
> just generated from that process.  Reload the page and a) the thumbnail
> is randomly selected, and b) album_image.txt gets over written with the
> new image path.
>
>     I woulda thunk album_image.txt, containing the correct path, and
> valid image file, would be re-used in (re)generating album thumbnails,
> and not over written with a new random image.
>
> --
> H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
>   +--------------------------------------------------------------------
>   Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
>   Director of Internet Operations / SysAdmin    .     800.441.3873 x130
>   Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave, #6
>   http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.
>
>
>
> _______________________________________________
> IDS-devel mailing list
> IDS...@li...
> http://lists.sourceforge.net/lists/listinfo/ids-devel

[Ids-devel] Admin logs

[Ashley M. K. <as...@pc...>]

    Okay, this will be my last post for the next few hours, I promise.
:)

    The 'View IDS logs' link, goes back to '/logs/', however, on systems
where directory indexes is turned off, this generates an error.  I would
suggest making that little block of text have links to the physical
files:

        [ Admin Log ]   last modified blah blah
        [ Comment Log ] last modified blah blah
        [ Error Log ]   last modified blah blah

        ...and have those in []'s be links to the physical file.

    ( somehow I think John's response to this will be, 'Sure.  Make a
theme that'll do that, and I'll include it.'  <grin> )

--
H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
  Director of Internet Operations / SysAdmin    .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave, #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

[Ids-devel] album_image (cont.)

[Ashley M. K. <as...@pc...>]

    I take that back.  Even if the image file does exist, and
album_image.txt contains the correct path and all, IDS still picks a
random image when generating a (new) album thumbnail.  Simple test:

    Pick image, set as album icon.  Verify that album_image.txt has the
correct path and image file in it.  Delete the <theme>.png file that was
just generated from that process.  Reload the page and a) the thumbnail
is randomly selected, and b) album_image.txt gets over written with the
new image path.

    I woulda thunk album_image.txt, containing the correct path, and
valid image file, would be re-used in (re)generating album thumbnails,
and not over written with a new random image.

--
H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
  Director of Internet Operations / SysAdmin    .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave, #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

[Ids-devel] album_image

[Ashley M. K. <as...@pc...>]

    For a while there, I thought I was going insane (or more than I
already am), trying to find out why my album icons weren't 'sticking'
from one theme to another.  Then it dawned on me, the data files don't
match!  So it randomly picks a different image.  Allow me to explain.
Take the following structure:

    /albums
        \-------- level 1 album
        |  \----- level 1.1 album
        |  \----- level 1.2 album
        |
        \-------- level 2 album
        |
        \-------- level 3 album
           \----- level 3.1 album
           \----- level 3.2 album
              \-- level 3.2.1 album
              \-- level 3.2.2 album


    If I wanted to take an image from level 3.2.2, and use it as the
main (level 1) thumbnail, I can't.  Well, I could, if I hit the 'random
icon' a zillion times till it finally picks it up.  Or, I can upload
that image into the (level 1) album, use it as an icon, then delete it
(since it really belongs in the other album, not the top level one).

    However, as far as the file album_image.txt is concerned, it's using
an image that (at some point) existed in that level 1 album.  If you
didn't generate your previews *before* you deleted that image, guess
what: your other themes are now faced with an invalid image, and will
randomly pick a new image from the structure.

    I know, I know.  You just can't please them all.

--
H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
  Director of Internet Operations / SysAdmin    .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave, #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

[Ids-devel] Request for Comments (LONG!)

[Ashley M. K. <as...@pc...>]

    Okay, this is really...what it is: a request for comments (and to
probe the list).  IDS is a great tool, and I can see great potential in
it.  Why do I say this?  Well, a little bit of what I do is in order
here.  I work for a photo lab, and when I see a tool such as IDS, my
brain goes into over drive.

    IDS is currently based on pixel sizes.  Unfortunately, in the *photo
printing* business, this means squat to us.  To the operator of the
printer, they need stuff in inches.  Think, 3.5x5", 4x6", 5x7",
8x10"...  You don't walk into a store and look for a picture frame that
has pixel dimensions on it.  No, you look for something that you're
familiar with: inches.

    I fully support IDS having pixel sizes...if all people are going to
do is look at it on the screen.  However, when it comes down to actually
downloading a large format file for the purposes of making a physical
print, suddenly the pixel dimensions no longer make sense.
Unfortunately, digital cameras don't allow for these dimensions, trust
me, they don't.  We deal with clients on a daily basis asking us why did
their image get cropped.  Well, uh, your pixel dimensions are not
proportionate to the print.  Note the following:

    Print Size:     Ratio:
    3.5x5 print  => 1.42
    4x6          => 1.5
    5x7          => 1.4
    8x10         => 1.25
    8x12         => 1.5
    11x14        => 1.27
    10x15        => 1.5


  Nikon Coolpix 995:                   Pentax IE200
  Available sizes:          Ratio      Available sizes:          Ratio
    Full (2,048 x 1,536)  => 1.33        Full (1,600 x 1,200)  => 1.33
    UXGA (1,600 x 1,200)  => 1.33        Half (800 x 600)      => 1.33
    SXGA (1,280 x 960)    => 1.33
    XGA (1,024 x 768)     => 1.33
    VGA (640 x 480)       => 1.33
    3:2 (2,048 x 1,360)   => 1.5

  Kodak DC3400:
  Available sizes:
    High (1,760 x 1,168)  => 1.51
    Standard (896 x 592)  => 1.51

    I can keep going...  As you can see, many of those sizes don't match
a physical print size.  So, we do what's best: we crop.


    So, what'd like to know is this: How many people see a need for
having a second unit (of measurement) built-in?

    My idea is (fairly) simple:  Add another preference, Units, with
'inches' or 'pixels' as possible options.  Have two arrays, one for
pixels, that contains the current available sizes, and an array for
inches, containing the dimensions for inches, converted into pixels.
For example:

    $units = 'pixel inches';
    $inchUnits = '360 432 504 720 1080';
       #360 = 5" | 432 = 6" | 504 = 7" | 720 = 10" | 1080 = 15"
    $pixelUnits = '512 640 800 1024 1600 original';

    Right now, IDS already displays images by resizing the largest
dimension to the size the user picked, and let the other dimension just
fall to whatever it is.  So, that part is already set.  Whatever the
unit selected, it just needs to use one array or the other.  In the drop
down menu, it just needs to display a human understandable list.  For
example, right now it says:

    tiny (512)
    small (640)
    medium (800)
    etc.

    The second (inches) menu can then read:

    3.5x5"
    4x6"
    5x7"
    etc.

    ...and have the form contain actual (pixel) values for those menu
options.

    This would make it very easy for someone ordering a picture to know
exactly which size they need for what print size.  You avoid having
someone pick, say the tiny version, and expect to be able to get a good
8x10.  Or, someone downloading the x-large file format, when it's
overkill for a simple 3.5x5 print.

--
H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
  Director of Internet Operations / SysAdmin    .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave, #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

[Ids-devel] Deletion of Albums?

[Ashley M. K. <as...@pc...>]

    Any particular reason why one can not delete an album (either just
the newly created one, or the entire album, including whatever photo
collection within)?  Yes, I can do it from the server level, but I don't
expect every user to have that ability - certainly not to know to go
through both albums, album-data and possibly image-cache, unless they
want to rebuild it.

--
H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
  Director of Internet Operations / SysAdmin    .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave, #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

[Ids-devel] Broken Images

[Ashley M. K. <as...@pc...>]

	[ Slap me silly and call me Suzy - I sent this message to John
directly, then realized I should've sent here in the first place.  Sorry
John. ]



    Stuff found on 0.71:

    - If a tiny file gets uploaded, in the admin page for that file, it
displays a broken image, although in album view, the file does get
displayed (with the only possible size changes available - sometimes
this means only 'original' is available)

    - This goes a long way since I too deal with it almost weekly, but,
the sorting of numbered items doesn't quite work.  Perl loves sorting by
individual character, as opposed to the full value, so you get things
like this: 1, 10, 15, 2, 23, 3, 4, 5, 56, 7, 9

    ...instead of, 1, 2, 3, 4, 5, 7, 9, 10, 15, 23, 56....

    The only way to overcome this, is to pad low numbers, so that it
sorts, like 01, 02, 03, 04, 05, 07, 09, 10, 15, etc., etc. 
Unfortunately, for IDS, this means having to do some pre-scanning of all
files, and determining who has a number, and what the highest digit
count is, then pad anything lower than that before sorting it.  Kind of
a hassle.

    - Someone else also posted this, and again, I believe it's a
Netscrape problem because it works find under IE: redirecting after
adding/removing/editing news items.  Netscrape displays a 'Found' page,
instead of actually redirecting to it (where IE redirects just fine).



--
H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
  +--------------------------------------------------------------------
  Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
  Director of Internet Operations / SysAdmin    .     800.441.3873 x130
  Photo Craft Laboratories, Inc.            .     3550 Arapahoe Ave, #6
  http://www.pcraft.com ..... .  .    .       Boulder, CO 80303, U.S.A.

[Ids-devel] Using IDS to generate static pages (Randy Maas' code)

[John M. <mo...@mu...>]

A while ago there was a discussion about using IDS to generate a static 
site. Randy Maas mentioned some code that he'd been using to accomplish 
this. It is now available here:
http://arwen.hn.org/~john/ids-devel/ids-static.tgz

It looks like you may also need some stuff from IDS 0.51:
http://prdownloads.sourceforge.net/ids/ids-0.51.tar.gz

Thanks, Randy.

John

[Ids-devel] IDS 0.71 released

[John M. <mo...@mu...>]

Hello.

IDS 0.71 (final) has been released:
http://ids.sourceforge.net/

I hope to make some serious progress with the IDS re-write this weekend.

John

[Ids-devel] authentication patch

[Craig M. <9j...@ql...>]

I created a patch against 0.71b2 with the changes that allow you to password
albums and put it at

http://mcfetridge.com/ids-0.71b2-auth.diff

however the padlock icon png file and login.html templates will need to be
retreived from

http://mcfetridge.com/ids-0.72a1.tar.gz

since they didn't get included in the patch (did i do something wrong?)

I boosted the version number to .72 since this change would not be
incorporated into .71 since it is close to being released.

Someone may want to go over my less that perfect translations in the
localizations files.

I noticed a patch on the sourceforge site that would make IDS display albums
before images, will this be applied to a development version?

craig

[Ids-devel] IDS 0.71b2 available

[John M. <mo...@mu...>]

Hello.

An IDS 0.71b2 release is now available:

http://arwen.hn.org/~john/ids-devel/

This release fixes a few more bugs:
- IDS 0.7 would attempt to generate previous/next thumbnails on image=20
pages for non-image files
- IDS would set the path on its cookies to "/" instead of wherever IDS=20=

was actually located

Assuming no big problems, this will be the last release before 0.71=20
final.

I'm giving up on trying to make this version of IDS compatible with=20
mod_perl. I think the code is just too nasty to fix. I'll remove the=20
references to mod_perl on the IDS website.

On the brighter side, I started work on a complete re-write of IDS this=20=

weekend. This version is designed from the ground up to work with=20
mod_perl. I got a lot further than I thought I would:

http://arwen.hn.org/~john/ids-adv/

The basic framework and code implementing the home page and album icon=20=

creation are in place. It already supports theme and language switching=20=

(watch the date formatting change!) and cookie storage and retrieval.=20
(None of the links work yet.)

I've changed the directory and program structure around some, so it=20
should be easy to install IDS once on a server and have multiple folks=20=

use it.

The code I've written so far is a lot more "objecty" than before, so it=20=

should be easier to extend. It's based on the CGI::Application module,=20=

which speeds up development considerably. All template processing is now=20=

handled with HTML::Template, which is a lot more efficient than what I=20=

came up with=96 it even has some caching support. Most IDS data files=20
(config, languages, news, and soon comments) are written and read using=20=

Config::General::Extended which parses Apache standard config files.=20
None of these modules include compiled code, so I hope to include them=20=

in the IDS distribution (they don't come with Perl.)

Here is what some of the revised data files look like:
http://arwen.hn.org/~john/ids-adv/ids.conf
http://arwen.hn.org/~john/ids-adv/data/sitenews.txt
http://arwen.hn.org/~john/ids-adv/localizations/Deutsch.txt

Some good reading:
http://www.perl.com/pub/2001/06/05/cgi.html
http://theoryx5.uwinnipeg.ca/CPAN/data/HTML-Template/Template.html
http://theoryx5.uwinnipeg.ca/CPAN/data/Config-General-
Extended/Extended.html

John

[Ids-devel] passwording albums

[Craig M. <9j...@ql...>]

Hi,

I was having issues using .htaccess files to password protect my albums
effectively as IDS would always generate a page of HTML with the image name.

I have made some changes so you can now protect albums by putting a
.htaccess file in the album's directory and when ids sees that it checks to
see if you have an authentication cookie for that album, if not you are
given a login screen and the cookie is set.

it is far from done as sub-directories are not protected so a user could
view albums beneath a protected album if they knew the name, and knowing the
URL to an image they could view it directly as well. I plan to upgrade my
apache past 1.3.12 so i can use setenvif directives in .htaccess files and
only allow images to be sent if the refferrer is IDS.

A lock icon is also overlayed on album-preview images.

I don't know if anyone else wants this functionality, but you can see a demo
of it at http://mcfetridge.com/gallery/ids-0.71/

the username ids and the password is devel.  my server is only a p166 with
64 megs of ram so it is a little slow.


If someone tells me how i would love to submit a patch and have this become
part of the standard IDS. is it just done with diff?

Craig McFetridge

Re: [Ids-devel] IDS 0.71b1 available

[Caleb E. <ca...@bk...>]

On Thu, Jun 07, 2001 at 08:15:52PM -0400, John Moose wrote:

> We're nearing a release, so I'd appreciate help looking for bugs.

	I have found:

	1. delete a news item from the admin interface -> takes you to
	a page that says "Location: index.cgi"; thats the entire
	contents of the page when I "View Source".  Presumably this
	was supposed to redirect me back to that URL.

	2. preferences.cgi doesn't work under mod_perl.  Gives the old
	cascade of errors ala:

Global symbol "$siteHeader" requires explicit package name at /var/www/photo/admin/preferences.cgi line 179.
Global symbol "$siteHeader" requires explicit package name at /var/www/photo/admin/preferences.cgi line 180.

	3. Main ids page is kicking out these few errors, though seems
	to be functioning ok:

Global symbol "$albumData" requires explicit package name at /var/www/photo/index.cgi line 207.
Global symbol "$albumIconName" requires explicit package name at /var/www/photo/index.cgi line 207.
Global symbol "$albumIconName" requires explicit package name at /var/www/photo/index.cgi line 213.
Global symbol "$home" requires explicit package name at /var/www/photo/index.cgi line 228.
Global symbol "$home" requires explicit package name at /var/www/photo/index.cgi line 231.
Global symbol "$home" requires explicit package name at /var/www/photo/index.cgi line 235.
Global symbol "$homesingle" requires explicit package name at /var/www/photo/index.cgi line 231.
Global symbol "$homesingle" requires explicit package name at /var/www/photo/index.cgi line 236.
Global symbol "$idscgi" requires explicit package name at /var/www/photo/index.cgi line 217.
Global symbol "$query" requires explicit package name at /var/www/photo/index.cgi line 182.
Global symbol "$query" requires explicit package name at /var/www/photo/index.cgi line 183.
Global symbol "$query" requires explicit package name at /var/www/photo/index.cgi line 186.
Global symbol "$theme" requires explicit package name at /var/www/photo/index.cgi line 184.
Global symbol "$theme" requires explicit package name at /var/www/photo/index.cgi line 186.
Global symbol "$theme" requires explicit package name at /var/www/photo/index.cgiline 207.

-- 
cae at bklyn dot org | Caleb Epstein | bklyn . org | Brooklyn Dust Bunny Mfg.

[Ids-devel] IDS 0.71b1 available

[John M. <mo...@mu...>]

Hi.

http://arwen.hn.org/~john/ids-devel/

IDS 0.71b1 brings some improvements to the administrative CGI:
- non-image files can be uploaded (and some improvements to the upload 
page)
- restructured the admin directory to avoid errors when IDS is installed 
in a cgi-bin directory or run under mod_perl. You will need to add 
something like this to your httpd.conf:

<Location /cgi-bin/ids/admin/templates>
    SetHandler default-handler
</Location>

- ".info" files in the image cache are deleted when their images are 
deleted
- gave buttons names that are more descriptive than "OK"

We're nearing a release, so I'd appreciate help looking for bugs.

Thanks,
John

Re: [Ids-devel] IDS 0.71a4 available

[John M. <mo...@mu...>]

That would be useful information, wouldn't it!

- fixed problems with previous/next image icons and mod_perl (last 
image's "next" icon would be from the previously viewed image)
- fixed problems with previous/next image icons and images with multiple 
periods in their names
- fixed JavaScript bug that affected Netscape Communicator on image 
pages (resize popup menu didn't work)
- fixed bugs in preferences (couldn't set preference for hitcounter, 
couldn't clear the field for "path to jpegtran", random album icon never 
selected the last image in an album)
- re-wrote the function generateAlbumIcon so that it wouldn't explode if 
album_icon.txt pointed to a non-existent file

Thanks,
John


On Monday, June 4, 2001, at 10:56 PM, Thomas Keegan wrote:

> What specifically is being fixed here?
>
> Tom
>
> ----- Original Message -----
> From: "John Moose" <mo...@mu...>
> To: <ids...@li...>
> Sent: Monday, June 04, 2001 7:53 PM
> Subject: [Ids-devel] IDS 0.71a4 available
>
>
>> Hello.
>>
>> I've been working on a bug-fix release for IDS 0.7:
>>
>> http://arwen.hn.org/~john/ids-0.71a4.tar.gz
>> http://arwen.hn.org/~john/photoalbum/
>>
>> Please give it a try and let me know if I've missed something.
>>
>> John
>>
>> (Busy reading the excellent "Writing Apache Modules with Perl and C."
>> I'm inspired!)
>>
>> _______________________________________________
>> IDS-devel mailing list
>> IDS...@li...
>> http://lists.sourceforge.net/lists/listinfo/ids-devel
>
>
> _______________________________________________
> IDS-devel mailing list
> IDS...@li...
> http://lists.sourceforge.net/lists/listinfo/ids-devel

Re: [Ids-devel] IDS 0.71a4 available

[Thomas K. <tk...@us...>]

What specifically is being fixed here?

Tom

----- Original Message ----- 
From: "John Moose" <mo...@mu...>
To: <ids...@li...>
Sent: Monday, June 04, 2001 7:53 PM
Subject: [Ids-devel] IDS 0.71a4 available


> Hello.
> 
> I've been working on a bug-fix release for IDS 0.7:
> 
> http://arwen.hn.org/~john/ids-0.71a4.tar.gz
> http://arwen.hn.org/~john/photoalbum/
> 
> Please give it a try and let me know if I've missed something.
> 
> John
> 
> (Busy reading the excellent "Writing Apache Modules with Perl and C." 
> I'm inspired!)
> 
> _______________________________________________
> IDS-devel mailing list
> IDS...@li...
> http://lists.sourceforge.net/lists/listinfo/ids-devel

[Ids-devel] IDS 0.71a4 available

[John M. <mo...@mu...>]

Hello.

I've been working on a bug-fix release for IDS 0.7:

http://arwen.hn.org/~john/ids-0.71a4.tar.gz
http://arwen.hn.org/~john/photoalbum/

Please give it a try and let me know if I've missed something.

John

(Busy reading the excellent "Writing Apache Modules with Perl and C." 
I'm inspired!)

Re: [Ids-devel] Re: Offline Mode

[Thomas K. <tk...@us...>]

Sounds intresting.

Would you be intrested in posting the patches\source?

Maybe we can bring it up to 0.7 levels.

I don't really care how slow it might be, and it sounds like what I was
describing.

Tom Keegan


----- Original Message -----
From: "Randy Maas" <ra...@ac...>
To: <ids...@li...>
Sent: Thursday, May 31, 2001 9:07 PM
Subject: [Ids-devel] Re: Offline Mode


> >In the past, I have always used static HTML to display my photo albums.
>
> >I'm not quite sure where to begin.
>
> I have a version of IDS which does that -- my home machine scarfs up the
> photo CD's, I label the photos, IDS generates a lot of static pages and
> image previews.  My machine then rysncs to send all of the files to a web
> server (really just another machine, but with fulltime internet access).
>
> The catch?  It's a hack, and it importing a full photo CD can cost my
> little old pentium 75 up to 45 minutes.  Its also based on IDS 0.4 or 0.5,
> depending on how far I got with patching.  Business has eaten my spare
time
> for the last couple of months, so I haven't gotten it up to 0.6 levels,
let
> alone 0.7 beta's.  It also uses Javascript in the html markup,  to allow
> the viewers to choose their favorite size.
>
> Randy
>
>
>
>
> _______________________________________________
> IDS-devel mailing list
> IDS...@li...
> http://lists.sourceforge.net/lists/listinfo/ids-devel
>

[Ids-devel] Re: Offline Mode

[Randy M. <ra...@ac...>]

At 03:48 PM 6/1/01 -0500, Brett Nemeroff wrote:
>Could this be done with a http mining tool? Like one of those websnarfers
that 
>grabs an entire tree for offline viewing?

I think it may have problems working.  Each page of an album, in a normal
IDS configuration, is generated by index.cgi on the fly. 

Randy

Re: [Ids-devel] Re: Offline Mode

[Anthony A. D. T. <aa...@ta...>]

>Could this be done with a http mining tool? Like one of those websnarfers
>that grabs an entire tree for offline viewing? 

Got one that works worth a damn?  wget sure doesn't.

Re: [Ids-devel] Re: Offline Mode

[Brett N. <br...@ne...>]

Could this be done with a http mining tool? Like one of those websnarfers that 
grabs an entire tree for offline viewing? Any ideas? Problem is, that drop down 
box would probably still show even in offline mode, but wouldn't work.


Has anyone ever used one of these tools? Can you recommend one?
-Brett


>>In the past, I have always used static HTML to display my photo albums.
> 
>>I'm not quite sure where to begin.
> 
> I have a version of IDS which does that -- my home machine scarfs up the
> photo CD's, I label the photos, IDS generates a lot of static pages and
> image previews.  My machine then rysncs to send all of the files to a web
> server (really just another machine, but with fulltime internet access).
> 
> The catch?  It's a hack, and it importing a full photo CD can cost my
> little old pentium 75 up to 45 minutes.  Its also based on IDS 0.4 or 0.5,
> depending on how far I got with patching.  Business has eaten my spare time
> for the last couple of months, so I haven't gotten it up to 0.6 levels, let
> alone 0.7 beta's.  It also uses Javascript in the html markup,  to allow
> the viewers to choose their favorite size.
> 
> Randy
> 
> 
> 
> 
> _______________________________________________
> IDS-devel mailing list
> IDS...@li...
> http://lists.sourceforge.net/lists/listinfo/ids-devel

[Ids-devel] Re: Offline Mode

[Randy M. <ra...@ac...>]

>In the past, I have always used static HTML to display my photo albums.

>I'm not quite sure where to begin.

I have a version of IDS which does that -- my home machine scarfs up the
photo CD's, I label the photos, IDS generates a lot of static pages and
image previews.  My machine then rysncs to send all of the files to a web
server (really just another machine, but with fulltime internet access).

The catch?  It's a hack, and it importing a full photo CD can cost my
little old pentium 75 up to 45 minutes.  Its also based on IDS 0.4 or 0.5,
depending on how far I got with patching.  Business has eaten my spare time
for the last couple of months, so I haven't gotten it up to 0.6 levels, let
alone 0.7 beta's.  It also uses Javascript in the html markup,  to allow
the viewers to choose their favorite size.

Randy

Re: [Ids-devel] 8 meg apache processes with mod_perl

[John M. <mo...@mu...>]

Code profiling show that the calls to ImageMagick (and CGI.pm) are the=20=

slowest sections in IDS, so I assumed that they are the things that=20
people would most want pre-compiled.

The current implementation of IDS requires that Image::Magick be loaded=20=

every time IDS is run. I'm hoping that this won't be the case in 0.8,=20
where I plan to implement an template-driven model=96 only the code=20
necessary to handle the current request will be run. I don't think this=20=

will make much of a difference with mod_perl, though, because I'd still=20=

want Image::Magick pre-compiled and that means a lot of memory will be=20=

required.

Ideas?

John

On Tuesday, May 29, 2001, at 10:31 PM, Craig McFetridge wrote:
> I understand the apache processes are 8 megs when you preload CGI.pm=20=

> and all
> the ImageMagik stuff.  I assume most of that is from ImageMagik.  Does
> imagemagik really need to be preloaded? It's too bad there isn't an=20
> easy way
> to make a lite version of IDS that doesn't do any image resizing, only
> generates the HTML for the albums.  this would probably be quite a bit
> faster, although probably not worth the effort.
>
> I like the idea of having clean URLs but you would have to use POST on=20=

> forms
> instead of just tacking variables onto the end of the URLs. again it=20=

> might
> not be worth the effort.
>
> You can always see which images are being viewed in your server logs=20=

> anyway.
>
> craig
>
>
> _______________________________________________
> IDS-devel mailing list
> IDS...@li...
> http://lists.sourceforge.net/lists/listinfo/ids-devel

Re: [Ids-devel] IDS 0.7 bug

[John M. <mo...@mu...>]

This fix will be in the next release, along with a "Most Popular..." =
CGI.

I really like the URL idea. I'll try to include that in the major=20
release=96 it's going to be a biggie.

John


On Tuesday, May 29, 2001, at 09:03 PM, Oren Teich wrote:
> There appears to be a bug in 0.7 related to the stats.
> idsShared.pm is missing a line like:
>
>         $collectstats =3D $preference{collectstats} if exists=20
> $preference{collectstats};
>
> I added this in, and the stats are working again.
>
> On a related but different topic, I love my webstats program, and want=20=

> to be able to continue using it to track how popular my web pages are. =
=20
> Although I can configure it to parse out the CGI stuff,I was thinking=20=

> it might also be nice to change the URL's to look perhaps like this:
>
> http://www.teich.net/ids/index.cgi/Animals/Picture.JPG
>
> This would allow everyone to use their plain jane web stats program=20
> with minimal impact.
> However, it would require significant changes to IDS, inclduing=20
> deducing the image from the URL and other fancy hacks.
>
> I'm just throwing this out there -- I recognize that it would require=20=

> some major changes.  thoughts?
>
> Oren
>
>
> _______________________________________________
> IDS-devel mailing list
> IDS...@li...
> http://lists.sourceforge.net/lists/listinfo/ids-devel