Menu
▾
▴
ids-devel — IDS developers use this list
You can subscribe to this list here.
| 2001 |
Jan
(2) |
Feb
(48) |
Mar
(16) |
Apr
(14) |
May
(42) |
Jun
(36) |
Jul
(57) |
Aug
(13) |
Sep
(2) |
Oct
(23) |
Nov
(17) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(5) |
Feb
|
Mar
(10) |
Apr
(1) |
May
(6) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(12) |
Oct
(26) |
Nov
(11) |
Dec
(37) |
| 2003 |
Jan
(11) |
Feb
(27) |
Mar
(5) |
Apr
(21) |
May
(11) |
Jun
(38) |
Jul
(8) |
Aug
(29) |
Sep
(2) |
Oct
|
Nov
(7) |
Dec
(5) |
| 2004 |
Jan
(5) |
Feb
(2) |
Mar
(19) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
| 2005 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(8) |
|
From: John M. <mo...@mu...> - 2001-02-28 17:48:59
|
Specifically, I'm interested in using the data generated by the hitcounters to create a gallery containing the most popular images on a site. IDS' most popular features have been those that build a sense of community- the guest comments, for example. John on 2/28/01 12:39 PM, Caleb Epstein at ca...@bk... wrote: > On Tue, Feb 27, 2001 at 09:48:12PM -0500, John Moose wrote: > >> Does anyone have any suggextions on implementing image and album >> hitcounters? I'm planning to work on that next. > > I can't think of anything more useless than hit counters on > web pages. Why would anyone want these? > > Personally, I'd like to see some additional ImageMagick > functionality available from the admin front end, specifically > being able to brighten or darken photos (I guess this is > changing the gamma), cropping (I suspect this will be hard to > implement -- how do you indicate the crop marks?) and maybe > more. |
|
From: Caleb E. <ca...@bk...> - 2001-02-28 17:38:25
|
On Tue, Feb 27, 2001 at 09:48:12PM -0500, John Moose wrote: > Does anyone have any suggextions on implementing image and album > hitcounters? I'm planning to work on that next. I can't think of anything more useless than hit counters on web pages. Why would anyone want these? Personally, I'd like to see some additional ImageMagick functionality available from the admin front end, specifically being able to brighten or darken photos (I guess this is changing the gamma), cropping (I suspect this will be hard to implement -- how do you indicate the crop marks?) and maybe more. -- cae at bklyn dot org | Caleb Epstein | bklyn . org | Brooklyn Dust Bunny Mfg. |
|
From: John M. <mo...@mu...> - 2001-02-28 02:46:54
|
Have a look at: http://arwen.hn.org/~john/ids-0.6/ Try clicking the new "View recent comments..." link. Let me know what you think. It's displaying the last entries added to the comment log (up to 10). You can download an archive from the usual place. Does anyone have any suggextions on implementing image and album hitcounters? I'm planning to work on that next. John |
|
From: Randy M. <ra...@ac...> - 2001-02-28 01:26:30
|
I have attached a non-functioning test, roughly similar to what would go into a CPAN module. Feel free to use it; I must say that it will not work completely. Why am I sending a half functioning test? I am hoping that it will be useful to some folks. I stopped working on it, to put more effort into submitting patches to make idsShared.pm pass it. What does it do? 1. It tests loading the module idsShared.pm 2. It uses warning and taint checking 3. It tries to call some subroutines. In particular, it will fail for two reasons: a. there is still something in idsShared.pm that is signalling a taint/warning message b. It tries to test a subroutine that doesn't exist yet Obviously more tests can be added (perversity encouraged) Randy. |
|
From: Randy M. <ra...@ac...> - 2001-02-28 01:08:10
|
>I am considering removing the ppath stuff unless you can think of a > reason to leave it in. I consider it obsolete (or just a bad choice on my part). I removed it awhile ago in my hacked up version. Randy |
|
From: Caleb E. <ca...@bk...> - 2001-02-27 23:40:28
|
I'm really on the ids bleeding edge now :)
Here's a patch for the very latest and greatest 0.6a6 which
fixes a bug where it constantly overwrites your
album_icon.jpg with the first image in the album.
--- ids-0.6/index.cgi Tue Feb 27 07:26:28 2001
+++ photo/index.cgi Tue Feb 27 18:37:28 2001
@@ -147,7 +147,7 @@
$prettyalbum =~ s/^\.+\///g; #trim off leading dot stuff
$prettyalbum =~ s/\#\d+_//g; # trims off numbers used for list ordering. ex: "#02_"
$prettyalbum =~ s/_/ /g; # replaces underscores with spaces
- my $previewName = "$albumData/$album".$albumIconName;
+ my $previewName = "$albumData/$album/".$albumIconName;
unless (-e $previewName) {
warn "$album: creating preview $previewName $origAlbum";
$previewName = generateAlbumPreview($origAlbum);
--
cae at bklyn dot org | Caleb Epstein | bklyn . org | Brooklyn Dust Bunny Mfg.
|
|
From: Randy M. <ra...@ac...> - 2001-02-27 20:44:21
|
Looks like both were my fault (*) Atleast I surely was tinkering with both things. >[23868] [2001/02/26 21:50:32] Variable "$logDir" is not imported at /var/www/photo/admin/index.cgi line 1524. I'm going to guess that John added the proper export for logDir to fix that. >creating path ../../image-cache/Work at ../idsShared.pm line 452 I don't have an up2date source tree next to me, but here is my guess. That looks like it got a double '../' prepended. The quick fix is probably to make sure that $imageCache or $albumData (I can't remember which defines the image-cache path at this moment) doesn't get a '../' prepended in the admin/index.cgi. A long term fix is to dump $ppath, but I'm not done with that patchball yet, and I think quite a few things still depende on $ppath. (*) Looks like my test didn't work. Randy |
|
From: John M. <mo...@mu...> - 2001-02-27 20:26:50
|
Specifying the location of the image-cache directory from the admin CGI: With the latest patch, the location is set to "../$imageCache". This causes problems in the generatePreviewImage function in IDSshared. When this function is called from the admin CGI, a ppath value of "../" is passed. This means that the script will attempt to create the image-cache directory at "../../image-cache" instead of the correct "../image-cache". I am considering removing the ppath stuff unless you can think of a reason to leave it in. John On Tuesday, February 27, 2001, at 03:14 PM, Randy Maas wrote: > What was the nature of the bugs? > > Sweatin, > Randy > > > _______________________________________________ > IDS-devel mailing list > IDS...@li... > http://lists.sourceforge.net/lists/listinfo/ids-devel |
|
From: Caleb E. <ca...@bk...> - 2001-02-27 20:17:03
|
On Tue, Feb 27, 2001 at 02:14:26PM -0600, Randy Maas wrote: > What was the nature of the bugs? Sweatin, Randy The admin interface became essentially non-functional: This noe got fixed by John lickety split and was causing admin/index.cgi to just not load at all: [23868] [2001/02/26 21:50:32] Variable "$logDir" is not imported at /var/www/photo/admin/index.cgi line 1524. [23868] [2001/02/26 21:50:32] Global symbol "$logDir" requires explicit package name at /var/www/photo/admin/index.cgi line 1524. But then this one cropped up once it got fixed, when clicking on an album in admin mode: [1778] [2001/02/27 08:39:56] creating path ../../image-cache/Work at ../idsShared.pm line 452 main::createDisplayImage(100, '../', '../albums/Work/9-west-day.jpg') called at /var/www/photo/admin/index.cgi line 1775 main::generateAlbumView() called at /var/www/photo/admin/index.cgi line 634 main::generateViewAlbum() called at /var/www/photo/admin/index.cgi line 70 [1778] [2001/02/27 08:39:56] mkdir ../../image-cache: Permission denied at ../idsShared.pm line 453 -- cae at bklyn dot org | Caleb Epstein | bklyn . org | Brooklyn Dust Bunny Mfg. |
|
From: Randy M. <ra...@ac...> - 2001-02-27 20:11:36
|
What was the nature of the bugs? Sweatin, Randy |
|
From: Daniel M. <dtm...@ho...> - 2001-02-27 19:03:50
|
"Anthony A. D. Talltree" <aa...@ta...> writes: > >you using IDS for, where people wouldn't already have the ability to > >upload arbitrary files by other means? Also, whose security is > >compromised by this? > > Imagine a zip file that contains ../index.cgi, which itself contains > > #!/bin/sh > rm -rf /usr/local/apache > > or such, in the default case where IDS isn't running under suexec. Ah, so you were imagining opening the zipfile on the server, instead of simply having a zip file available for download, the way mp3 files are. I misunderstood. In that case I would think that something could be done with the File::Archive module (Or the Archive::Zip module) to limit the possible damage a user could cause. This should probably be an optional add-on, as I'd hate to introduce additional prerequisites for ids. |
|
From: Daryl S. <dw...@mi...> - 2001-02-27 18:55:43
|
Javascript can be useful, but it makes the page load slower. Javascript pop-up menus under Solaris are glacial. I wouldn't require it. As for using zip.... that seems like stuff IDS shouldn't have to worry about. Write a CGI script for your webserver or use one of the following: Unix -> Unix.... rsync -avHS --update is your friend Windows -> Unix.... FTPSync from www.fileware.com I just have a directory of same name as my album and then sync it using either of the above. Works great. While I'm plugging the dude's tools: Windows -> Windows... FileSync or CmdSync from www.fileware.com Patrick Devine wrote: > > On Tue, 27 Feb 2001, Anthony A. D. Talltree wrote: > > > > Do we want to require javascript-capable browsers? > > > > NoNoNo PLEASE No. Java causes Netscrape to dump core. > > > > >Create the abilty to upload a zip file > > > > I vote no on this for security reasons. A zip file could contain *anything*. > > Java and JavaScript are two different things, but I would argue that you > don't want to have to make a user _require_ either of them. Plus Netscape > JavaScript is different than IE JavaScript and that leads to a lot of > problems. > > As for a uploading zip files, I'm really not too keen on that > either. What I've been doing is just tar'ing up my photos, transferring > them over to the server and just copying them into the album directories, > and it works pretty well for the most part. > > --Patrick. > > _______________________________________________ > IDS-devel mailing list > IDS...@li... > http://lists.sourceforge.net/lists/listinfo/ids-devel |
|
From: Anthony A. D. T. <aa...@ta...> - 2001-02-27 18:47:16
|
>Java != Javascript. Nonetheless it kills Netscrape just as dead. >you using IDS for, where people wouldn't already have the ability to >upload arbitrary files by other means? Also, whose security is >compromised by this? Imagine a zip file that contains ../index.cgi, which itself contains #!/bin/sh rm -rf /usr/local/apache or such, in the default case where IDS isn't running under suexec. |
|
From: Daniel M. <dtm...@ho...> - 2001-02-27 18:37:41
|
"Anthony A. D. Talltree" <aa...@ta...> writes: > > Do we want to require javascript-capable browsers? > > NoNoNo PLEASE No. Java causes Netscrape to dump core. Java != Javascript. In fact, the two have little relationship at all, other than the fact that the Java hype was just getting started when Netscape needed a name for its scripting language. > >Create the abilty to upload a zip file > > I vote no on this for security reasons. A zip file could contain *anything*. I don't understand the security implications here. What scenario are you using IDS for, where people wouldn't already have the ability to upload arbitrary files by other means? Also, whose security is compromised by this? |
|
From: Anthony A. D. T. <aa...@ta...> - 2001-02-27 18:27:17
|
>Java and JavaScript are two different things, Same sh*t, different color. |
|
From: Patrick D. <pa...@va...> - 2001-02-27 18:18:02
|
On Tue, 27 Feb 2001, Anthony A. D. Talltree wrote: > > Do we want to require javascript-capable browsers? > > NoNoNo PLEASE No. Java causes Netscrape to dump core. > > >Create the abilty to upload a zip file > > I vote no on this for security reasons. A zip file could contain *anything*. Java and JavaScript are two different things, but I would argue that you don't want to have to make a user _require_ either of them. Plus Netscape JavaScript is different than IE JavaScript and that leads to a lot of problems. As for a uploading zip files, I'm really not too keen on that either. What I've been doing is just tar'ing up my photos, transferring them over to the server and just copying them into the album directories, and it works pretty well for the most part. --Patrick. |
|
From: Anthony A. D. T. <aa...@ta...> - 2001-02-27 16:50:35
|
> Do we want to require javascript-capable browsers? NoNoNo PLEASE No. Java causes Netscrape to dump core. >Create the abilty to upload a zip file I vote no on this for security reasons. A zip file could contain *anything*. |
|
From: John M. <mo...@mu...> - 2001-02-27 14:44:28
|
I've taken down this archive. There are some serious problems with the admin CGI and the image-cache. (Thanks to Caleb Epstein for finding them.) I'll try to get a new version out this evening. John On Monday, February 26, 2001, at 05:41 PM, John Moose wrote: > Hello. > > IDS 0.6a6 is now available. This pre-release includes Randy Maas' latest > patches and some code to improve the display of EXIF tags generated by > Canon > digital cameras. > > http://arwen.hn.org/~john/ > > John > > > _______________________________________________ > IDS-devel mailing list > IDS...@li... > http://lists.sourceforge.net/lists/listinfo/ids-devel |
|
From: John M. <mo...@mu...> - 2001-02-27 00:34:18
|
Sorry for the long message, but it's jam-packed with good ideas. The following are user-submitted feature requests I've received over the past week: on 2/20/01 7:21 AM, Carlos Jorge Andrade wrote: > Hi there... > I'm a fan of your IDS system. :-) > I've a question that i think is more like a sugestion. > In the admin zone why can't we DELETE an album ? > We can rename, add but not delete one. Or can we ? > > Thanks. This would make the admin interface a lot more useful, but I worry about making it too easy for someone to accidently delete a lot of photos. Are there any javascripters in the house? It looks like it would be pretty easy to add a pop-up confirmation dialog box. (This would be useful in other places, too.) Do we want to require javascript-capable browsers? on 2/22/01 2:41 PM, Brett Nemeroff wrote: > Hey John, > I've finally got IDS up and running on my webserver. I've actually got two > sites running IDS now, http://www.nekula.com and http://www.nemeroff.com > > Mine is www.nemeroff.com <http://www.nemeroff.com> the other one is > completely password protected. Just as an interesting piece of information, he > has over 2000 pictures on there and it works great (version 0.52). I love the > shutterfly feature, haven't used it yet, but want to give it a whirl. > > I had a couple of "simple" recommendations for the program. First of all, I > saw that in the TODO that you are planning (as a long term goal) to be able to > run the system globally. so that multiple users could setup their own albums. > I think this is an excellent recommendation. I currently have to create > multiple copies of the CGI scripts. I have some other ideas: > > 1. Be able to specify a maximum size for image cache. One the max size is > reached, it starts overwriting/deleting the last accessed or something > intellegent like that. > 2. Files are hard to save from the website.. they end up having all of the > special characters (like %20 for spaces) is there any way to fix that?? For > example, goto an IDS site and save a pic to your local computer by right > clicking on it. > 3. A description field for each picture would be nice as an option (that you > could have on every pic or just a few. Empty descriptions wouldn't even show > up). I know you currently support this in comments, but you have to scroll all > the way down to the bottom of the picture. And comments get moved around as > they get added. > 4. I like the idea also in the TODO for generating statistics such as most > popular photos, hit counters, etc. > 5. Maybe the capability of having people subscribe to the photo album to be > notified of changes? > 6. Allow a public photo album where anyone can upload pictures. May need > multiple security levels for this to work. > 7. Include an option to email IDS admin when someone adds a comment. > 8. Create the abilty to upload a zip file containing directory structures and > JPG files. I actually added this functionality in 0.51 but it didn't work for > long. I think I had a permissions problem. It was about 4 lines of code. > Basically right after you upload the ZIP file, it checks the extension, if > it's ZIP it uncompresses it and removes the ZIP file. This is VERY VERY > useful. In fact, I'd almost say it's extreamly important. I almost never just > add one picture at a time. So the admin interface is almost useless for me. I > take 100s of pics on my digital camera (I have a 1G microdrive in my digital > camera) and then I want to dump all of the pics from the camera into the > website. I typically stage them on my PC, sort them, zip them, and then it > would be nice to be able to send it to the "photo server" via a zip file. > > BTW, that last recommendation is the only one I'm really wanting right now. > > Those are my current recommendations. I'm overall very happy with the product. > I think it's very easy to use, setup and it looks great. Send my thanks to you > and your team on your great work. > > Thanks again, > Brett Several of these ideas sound good to me. on 2/24/01 4:53 AM, Tom Heady wrote: > just got IDS running at my family website. > > thought I would give you congrats for the work you have done, this thing is > great. > I just got through importing a bunch of images and comments that were on my > half assed photo album, and found a few things. > > a couple of things that I would like to see: > -when editing an image, it would be nice to be able to edit the comments and > imagename without having to submit twice > -the ability to mass delete more than one image at a time (mabye from the main > image page for the album...checkboxes and all) > -the ability to move an image to another album from the image edit page (mabye > mass move too, like the delete?) > -upload multiple images from the web browser. (possible? i dont know if the > file-upload field allows this...nevermind this wont work :( ) > -add the ability to turn off visibility of ip address and time (or make time > smaller) in comments to the preferences page > > > possible bugs: > if the image is renamed to end in a "." eg "this is my image name.." it can > cause problems in the image interface. > > > documentation additions: > I have redhat 6.2 > I could not get the .htaccess to work (never had a need before) so i had to > look up this bit of info: > > you have to set AllowOverride to AuthConfig (mine was set to None) in the file > access.conf. > > mine was here: /etc/httpd/conf/ > > also my version of apache (1.3.9-4) had problems with the <Limit GET> and > </Limit> lines in .htaccess, so i removed them > > once you do that then restart apache. it will then notice your .htaccess file > > http://www.redhat.com/support/docs/faqs/RH-apache-FAQ/c135.html#AEN137 > http://www.apacheweek.com/features/userauth > > thanks again for the great software...hopefully i will get time to contribute! > ---tom I'll make the documentation changes, but I thought that the multiple image selection (maybe checkboxes?) would be a fun idea for someone to play with. on 2/26/01 7:46 AM, Denis Karpov wrote: > hello John ! > first of all thank you for that great piece of job you've done on > IDS image displaying system. it's really looks cool, easy to setup > and works like a charm. > > there are couple of things i'd like to propose. > > 1. private galleries > access to some galleries with authentication > > 2. image order in album > it'd be good to have control of the order of images (thumbnails) in > the album title page. for now it is possible to do thru filenames only > (since they are displayed in alphabetic order) > > keep up good work ! > > with best regards, > Denis. People have been asking for private album support for quite some time, but I've never been able to come up with a good (elegant & secure) way to implement it. John |
|
From: John M. <mo...@mu...> - 2001-02-27 00:32:24
|
Hello. IDS 0.6a6 is now available. This pre-release includes Randy Maas' latest patches and some code to improve the display of EXIF tags generated by Canon digital cameras. http://arwen.hn.org/~john/ John |
|
From: Randy M. <ra...@ac...> - 2001-02-25 20:52:46
|
Good afternoon, Another small set of patches. These patches basically remove the main::scaledOverlayImage from the idsShared.pm module, and its initialization from the index.cgi and admin cgi scripts. Randy |
|
From: Randy M. <ra...@ac...> - 2001-02-18 21:44:27
|
I think you've made a good choice. The source data shouldn't be changed, although image rotation seems to be an acceptable exception to this. (I only reuse the image-cache, since its already there 8) Randy Maas |
|
From: Randy M. <ra...@ac...> - 2001-02-18 21:41:20
|
These patches remove $currentTime, $currentDate, and $logDir from the main name space, and place them in the idsShared namespace. This also forces a "bug fix" where the global time variable was being used to store a local variables data. Randy Maas |
|
From: John M. <mo...@mu...> - 2001-02-18 00:04:26
|
That was easier than I thought... The second release of the day, IDS 0.6a5, is available. http://arwen.hn.org/~john/ Description files and album icons are now stored in the "album-data" directory (this name can be changed easily.) Much like the image-cache, directory, the script builds a directory structure that matches that of the albums directory. Because we now don't have to worry about the visibility of album icons, I changed the default name of these files to "album_icon.jpg." For the sake of consistancy, album descriptions now reside within the directory they describe and are named "album_description.txt." Please let me know what you think. John on 2/17/01 5:53 PM, John Moose at mo...@mu... wrote: > Thanks. > > I'm not sure about using the image cache for album preview images. I like > the fact that nothing valuable is kept in there so I can clear it out from > time to time. If a custom album icon had been created, it would be lost. > > I've been wanting to move everything that isn't an original image (album > previews and comments) out of the albums directory. Many people have > complained about IDS requiring write access to the directories that contain > their original images. I've been putting the change off because it would > break people's current sites. > > I think I'll get started on this. Unless someone has a better suggestion, > I'll call the new directory "album-data." > > I wonder how hard it would be to write a program to convert from the old > layout to the new... > > John |
|
From: John M. <mo...@mu...> - 2001-02-17 22:52:40
|
Thanks. I'm not sure about using the image cache for album preview images. I like the fact that nothing valuable is kept in there so I can clear it out from time to time. If a custom album icon had been created, it would be lost. I've been wanting to move everything that isn't an original image (album previews and comments) out of the albums directory. Many people have complained about IDS requiring write access to the directories that contain their original images. I've been putting the change off because it would break people's current sites. I think I'll get started on this. Unless someone has a better suggestion, I'll call the new directory "album-data." I wonder how hard it would be to write a program to convert from the old layout to the new... John on 2/17/01 3:37 PM, Randy Maas at ra...@ac... wrote: > Attacheed are three little patches that make the albumIconName be relative > to the imageCache. This patch is separate for two reasons; one I clipped > that part out of the previous patch to John*. Two, this patch will > probably break current settings for album icon images. Album icon images, > to the best of my understanding, are stored in the albums source > directory, but don't risk overwriting a legitimate album picture because > the icon's file name is prefixed with a '.' > > I don't use files that start with a '.', so there is a risk that the > icon filename may overwrite a real image. The solution is to place it in > the imagecache where there won't be a name collision. (Images in the > image-cache, have suffixes that distinguish them). > > > (*) I edit patches by hand since my diffs are otherwise kinda big. > > Now to download 6a4, > Randy Maas > > |
7 messages has been excluded from this view by a project administrator.
