ginp-developers Mailing List for Java Photo Gallery Web Application (Page 5)
Brought to you by:
burchbri,
dougculnane
Menu
▾
▴
ginp-developers — ginp Developers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(35) |
Feb
(7) |
Mar
(18) |
Apr
(6) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(28) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(14) |
| 2009 |
Jan
(31) |
Feb
(8) |
Mar
(21) |
Apr
(30) |
May
(86) |
Jun
(78) |
Jul
(41) |
Aug
(33) |
Sep
(20) |
Oct
(38) |
Nov
(9) |
Dec
(4) |
| 2010 |
Jan
|
Feb
|
Mar
(32) |
Apr
(53) |
May
(20) |
Jun
(18) |
Jul
(9) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2014 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Justin <ju...@ww...> - 2005-01-26 00:19:41
|
The fix between 0.20 and 0.21 that doug listed as a security fix was caused due to a bug in the use of the java preferences api that would cause java to not save preferences properly in some instances causing ginp to reset to an unconfigured state after the appserver was restarted. Users should upgrade as the bug could allow an attacker to browse pictures they weren't supposed to have access to. On Tue, 25 Jan 2005 15:00, Justin wrote: > > The fix was to keep people out of the setup application once it had > been configured. The fix was to the setup wizard code in cvs that had > not yet been released at the time the fix was made. > > On Tue, 25 Jan 2005 6:01, Doug Culnane wrote: >> Dear Thomas, >> >> Thanks for your mail. >> >> I will invite Justin to answer your mail has he understands this >> better than me. >> >> All the best, >> >> Doug >> >> >> Thomas Kristensen wrote: >> >>> Hi, >>> >>> We have noticed that you have made a "security fix". Is this >>> exploitable and if so who can exploit how and what is the impact? >>> >>> >> >> >> -- >> Doug Culnane >> do...@cu... >> www.culnane.net > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Ginp-developers mailing list > Gin...@li... > https://lists.sourceforge.net/lists/listinfo/ginp-developers |
|
From: Justin <ju...@ww...> - 2005-01-25 21:05:09
|
The fix was to keep people out of the setup application once it had been configured. The fix was to the setup wizard code in cvs that had not yet been released at the time the fix was made. On Tue, 25 Jan 2005 6:01, Doug Culnane wrote: > Dear Thomas, > > Thanks for your mail. > > I will invite Justin to answer your mail has he understands this better > than me. > > All the best, > > Doug > > > Thomas Kristensen wrote: > >> Hi, >> >> We have noticed that you have made a "security fix". Is this >> exploitable and if so who can exploit how and what is the impact? >> >> > > > -- > Doug Culnane > do...@cu... > www.culnane.net |
|
From: Justin <ju...@ww...> - 2005-01-25 20:08:58
|
I think making thumbnails is a good idea. However, this kind of per request image scaling is going to use a lot of memory and cpu and can be just as easily be done on the client at the cost of slightly more bandwidth. On Tue, 25 Jan 2005 10:01, Justin wrote: > I looked at the code and when the height is on you have to take a 500k > compressed image, decompress it and make another copy of it > transformed. This is a very memory intensive operation. When you > don't put the height parameter on it you can just stream it off of the > disk a byte at a time and this works fine. > > Regards, > > Justin > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Ginp-developers mailing list > Gin...@li... > https://lists.sourceforge.net/lists/listinfo/ginp-developers |
|
From: Doug C. <do...@cu...> - 2005-01-25 18:07:59
|
I could not reproduce this error locally only on my live webserver (which has been up 495 days). The tomcat server has been running a few months and so I stopped and started it. The problem was fixed once it started. Therefore I think that this is not really a ginp problem. The resizing of images is a big computing tasks but it is needed to make the application preform well (or at all) on low bandwidth connections. The resize is fast on a server and only one image is resized at a time. The thumbnails come from the disk and are made once by a background thread. Therefore a test gallery of 1000 pic will not make a big difference. I think that the culnane.navidat.com webserver just got in a bad state. If it happens again I will try to increase the memory tomcat used at start up. If you think I have missed something serious then let me know. All the best, Doug Justin wrote: > Doug Culnane wrote: > >> >> It is still there: >> http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG&height=647 >> >> >> > > Doug, > > I think you're running out of memory because of the height > parameter. If you remove it it runs fine. Just click on the link > below to see what I mean. > > http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG > > > I looked at the code and when the height is on you have to take a 500k > compressed image, decompress it and make another copy of it > transformed. This is a very memory intensive operation. When you > don't put the height parameter on it you can just stream it off of the > disk a byte at a time and this works fine. > > Regards, > > Justin > > > -- Doug Culnane do...@cu... www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-25 13:56:47
|
Dear Thomas, Thanks for your mail. I will invite Justin to answer your mail has he understands this better than me. All the best, Doug Thomas Kristensen wrote: >Hi, > >We have noticed that you have made a "security fix". Is this >exploitable and if so who can exploit how and what is the impact? > > > -- Doug Culnane do...@cu... www.culnane.net |
|
From: Justin <ju...@sq...> - 2005-01-25 09:56:56
|
Doug Culnane wrote: > > It is still there: > http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG&height=647 > > > Doug, I think you're running out of memory because of the height parameter. If you remove it it runs fine. Just click on the link below to see what I mean. http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG I looked at the code and when the height is on you have to take a 500k compressed image, decompress it and make another copy of it transformed. This is a very memory intensive operation. When you don't put the height parameter on it you can just stream it off of the disk a byte at a time and this works fine. Regards, Justin |
|
From: Doug C. <do...@cu...> - 2005-01-25 08:00:40
|
Some more bad ideas for the HowTo store picture data: Originally I wanted to store data in EXIF format. This means the data always stays with the picture :-). But :-(: - Some picture editors destroy the EXIF data when they save the modified file. - A bug in the ginp means that it could corrupt the picture. So I decided to make the original pictures read only (because I am a coward). - You still have the same problem indexing and searching data that you have with XML. If the data is on disk in XML files a search could start a new thread in the background that feeds the array of the models current pictures. Therefore the search can happen slowly in the background but the user gets to start browsing the results immediately. This would scale because the data is not in memory but it would be very slow, but it would be usable maybe....? Doug -- Doug Culnane do...@cu... www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-24 18:08:33
|
It is still there: http://culnane.navidat.com/dc/ginppic?path=%2FBoats+and+Builds%2F&name=DSC07655.JPG&height=647 -- Doug Culnane do...@cu... www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-24 18:05:43
|
Bug fixed by reloading Web Application! Very wired.... But forget it unless you get the same problem: It may have been a browser cache thing with some old link encodings....? Got to go. Doug Doug Culnane wrote: > I think I have another silly mistake in my code (or it is a URL EnCode > DeCode problem) : > > 2005-01-24 18:21:14 StandardWrapperValve[ginp Picture Servlet]: > Servlet.service() for servlet ginp Picture Servlet threw exception > javax.servlet.ServletException: Servlet execution threw an exception > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) > > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) > > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) > > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) > > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) > > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) > > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) > > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) > > at > org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) > > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) > > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) > > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) > > at > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) > > at > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) > > at > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) > at > org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594) > > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392) > > at > org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565) > > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619) > > at java.lang.Thread.run(Thread.java:536) > ----- Root Cause ----- > java.lang.OutOfMemoryError > > > > Generated by: > http://culnane.navidat.com/dc/moth/ginpservlet?cmd=showpicture&colid=0&path=%2FBoats+and+Builds%2F&name=DSC07655.JPG > > > I will try to fix this ASAP (and release again...) but I have to go > now, so I am posting this to the list to see if the magic fairies do > it for me... > > All the best, > > Doug > > -- Doug Culnane do...@cu... www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-24 17:56:17
|
I think I have another silly mistake in my code (or it is a URL EnCode
DeCode problem) :
2005-01-24 18:21:14 StandardWrapperValve[ginp Picture Servlet]: Servlet.service() for servlet ginp Picture Servlet threw exception
javax.servlet.ServletException: Servlet execution threw an exception
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
----- Root Cause -----
java.lang.OutOfMemoryError
Generated by:
http://culnane.navidat.com/dc/moth/ginpservlet?cmd=showpicture&colid=0&path=%2FBoats+and+Builds%2F&name=DSC07655.JPG
I will try to fix this ASAP (and release again...) but I have to go now,
so I am posting this to the list to see if the magic fairies do it for me...
All the best,
Doug
--
Doug Culnane
do...@cu...
www.culnane.net
|
|
From: Doug C. <do...@cu...> - 2005-01-24 17:09:45
|
Have released version 0.21 and updated the website. -- Doug Culnane do...@cu... www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-24 16:12:34
|
> I was thinking last night about killer features for ginp that > would make it much more popular and I decided that they cannot be done > without a database. One example of a great feature would be to show a > random picture. If you had thousands of pictures keeping these all in > memory or doing directory traversals of meta data would be > ridiculously slow. You may well be right. Are we trying to make an application that can cope with thousands of pictures? (Why not) > Another would be rating pictures and being able to view the highest rated. I think that this could be very cool. Every time a big version of a picture is requested a date/time stamp is logged. We could then sort by most popular this month.... Been in my ToDos for a while but did not know HowToDo. > Again, xml does not scale for this. We could index the pictures via > MD5 hash of the file so even if you moved stuff around the database > could realize that the picture was the same one from earlier and find it. That would be great but what happens if I crop my picture using gimp? > We could make the database optional and just say that if you want > these extra features you have to have a database. That is a great Idea. I think that it is horses for courses. The basic ginp does what it dos now without storing data. It is a picture viewer and navigator. If you want to get cleaver then install mysql and add data to the presentation and have the extra features like searching.... > I could add a page to the setup that would let people put in their DB > info. Makes sense. > I have a lot of database app knowledge so I'll be able to get this > moving along pretty quickly. I too have a lot DB Web Ap knowledge and my own tools but they are not GPL so I would have to start from the beginning, which is maybe a good place to start. > > Regards, > Justin > Ok lets flirt with the idea of a database. I will go for it but I do not think that I want to program a file manager and a picture editor. " What ginp is not? ginp = Ginp Is Not a Picture manager ginp = Ginp Is Not gimP <http://www.gimp.org> The management of the files is NOT part of the application because there are better tools for copying renaming and moving files. Editing the photos is NOT part of the application because there are better tools for editing images. " I still think this is a good design brief. Bad Ideas...: - If we do a webdav interface we could intercept file moves and saves and correct the database references. - We could do a admin web interface to fix broken links with files. - We could put the files in the database like every PHP/MySQL picture gallery. - We tell users once files are there do not move or rename them, but you can edit them with your favorite picture editor. - We tell users once files are there do not edit them, but you can move them with your favorite file manager. - We index the file system and read xml data stick it in a database, for extra features. After data is jpg and xml data is moved or changed the admin user clicks the re-index button, and the data is reimported. Have you got a good idea or do you like one my good ideas? All the best, Doug -- Doug Culnane do...@cu... www.culnane.net |
|
From: Justin <ju...@sq...> - 2005-01-23 20:41:00
|
Doug Culnane wrote: > I hope you are not offended by my comment I just wanted to integrate the > wizard with the application more. I think the two should look the same > or similar. No offence taken :). > Lets stay with the XML idea then. There is so much development that > maybe a XML database project exists. This may allow us to say there is > the data index it and it does the rest and gives us an API for > searching...?? > > XSL may also give us some easy built in features for displaying pictures > and data on static exports..... > > I will continue my Schema and then work on Parsing the xml data. Then I > will look at creating the XML data from the web form. When this is done > maybe we have found a cool xml data engine thing and can build the > search feature. > I was thinking last night about killer features for ginp that would make it much more popular and I decided that they cannot be done without a database. One example of a great feature would be to show a random picture. If you had thousands of pictures keeping these all in memory or doing directory traversals of meta data would be ridiculously slow. Another would be rating pictures and being able to view the highest rated. Again, xml does not scale for this. We could index the pictures via MD5 hash of the file so even if you moved stuff around the database could realize that the picture was the same one from earlier and find it. We could make the database optional and just say that if you want these extra features you have to have a database. I could add a page to the setup that would let people put in their DB info. I have a lot of database app knowledge so I'll be able to get this moving along pretty quickly. Regards, Justin |
|
From: Doug C. <do...@cu...> - 2005-01-21 10:26:32
|
> I'm all for the src/war split but include the libs in the war, even if > it makes it huge because the users are going to have to download the > libs anyway to make the web-app work so we might as well make it easy > for them. > Agree, Will do when I release 0.21 soon. > > http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLEncoder.html says > that UTF-8 oughta work. They even use a u with two dots on top in the > example. You should see what it goes into the encoder as and comes > out as. The URLEncoder URLDecoder should reverse each other perfectly. The German Chars are not in the UTF-8 standard. > > I think the home page could use some cleaning up. It's a little plain > right now. We could also change the style of the homepage to look > like the setup. :) I went for plain and clear. I am not graphic designer so it is what it is. Maybe I will ask Patrick (pixelbyte) if he has any ideas about sexing it up. I hope you are not offended by my comment I just wanted to integrate the wizard with the application more. I think the two should look the same or similar. > > I don't want to do a DB either unless it does something really useful > for the app. Blojsom is a good example of not using a db. Of course > I also don't want to re-invent the db if we need it. If we want to do > a search engine we can use Apache Lucene or we can use a db if there's > a feature it's be really good for like picture rating. > > Lets stay with the XML idea then. There is so much development that maybe a XML database project exists. This may allow us to say there is the data index it and it does the rest and gives us an API for searching...?? XSL may also give us some easy built in features for displaying pictures and data on static exports..... I will continue my Schema and then work on Parsing the xml data. Then I will look at creating the XML data from the web form. When this is done maybe we have found a cool xml data engine thing and can build the search feature. All the best, Doug -- Doug Culnane do...@cu... www.culnane.net |
|
From: Justin <ju...@sq...> - 2005-01-21 09:29:42
|
Doug Culnane wrote: > I thought about this on the way to work this morning and came to the > same conclusion. Next release will have a ginp-src-v0.21.zip, > ginp-src-v0.21.tgz and a ginp.war file. Ok not a bad idea. > >> >> We want to go for the simplest possible install. It's ok to make >> developers and those who want to build it themselves do a little more >> work. However, regular users, who may not even know Java, who just >> want to download it and get the app to work should just be given a >> single bundled war to download so that they can copy ginp.war into the >> war dir and have it work without having to be aware of classpaths, >> etc. 8 megs is not a lot these days. I think that we are done >> growing for a while unless we add a db persistance layer. > > > If we split it it will be half the size (~4 MB). I'm all for the src/war split but include the libs in the war, even if it makes it huge because the users are going to have to download the libs anyway to make the web-app work so we might as well make it easy for them. > > Using the standard encoder is more elegant than my encoding. I was > confused because the links were passed through an encoder but it did not > do the + char. I can confirm that it works with my test files with > funny names. The German Chars do not work. I tried changing the > URLDecoder.decode(parameterValue,"UTF-8"); methods to ISO-8859-1 but it > did not help. http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLEncoder.html says that UTF-8 oughta work. They even use a u with two dots on top in the example. You should see what it goes into the encoder as and comes out as. The URLEncoder URLDecoder should reverse each other perfectly. > What are your thoughts on changing page 4 of the set up wizard to a > "Congratulations click here to go to the home page" We change the home > page to be a bit more sexy and/or clearer. We drop the select a style > per collection option. This makes it clearer, and simpler. We could > also use the style of the home page for the wizard so it looks more like > part of the delivered application rather than an add on. I think the home page could use some cleaning up. It's a little plain right now. We could also change the style of the homepage to look like the setup. :) > > You mention db. What are your thoughts on this? I want to avoid a db > because it is something else to set up and it makes moving pictures > complex. I like the idea of using a file manager for managing files. A > desktop program like gimp for editing pictures and a web application for > presenting them. I think that if the data is on the disk with the > picture it is easy to move it with the picture file. I also think that > the XML data can be parsed and an made into an in-memory searchable > index. However searching and sorting data is a job for a database. > What do you think? > I don't want to do a DB either unless it does something really useful for the app. Blojsom is a good example of not using a db. Of course I also don't want to re-invent the db if we need it. If we want to do a search engine we can use Apache Lucene or we can use a db if there's a feature it's be really good for like picture rating. |
|
From: Doug C. <do...@cu...> - 2005-01-21 09:22:15
|
>> I fixed the '+' encoding bug... the right way. I strongly >> recommend we do a 0.21 release before people hand out lots of >> permalinks using your custom encoding. > > > Using the standard encoder is more elegant than my encoding. I was > confused because the links were passed through an encoder but it did > not do the + char. I can confirm that it works with my test files > with funny names. The German Chars do not work. I tried changing the > URLDecoder.decode(parameterValue,"UTF-8"); methods to ISO-8859-1 but > it did not help. > From the JDK JavaDocs: /*Note:* The World Wide Web Consortium Recommendation <http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars> states that UTF-8 should be used. Not doing so may introduce incompatibilites./ Therefore German file names are not supported, and therefore I will add a note in the documentation. -- Doug Culnane do...@cu... www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-21 09:10:40
|
Justin wrote: > > Doug, > > Split the distribution into a src and war distribution but don't > make people have to download both the war and the lib to run ginp. I thought about this on the way to work this morning and came to the same conclusion. Next release will have a ginp-src-v0.21.zip, ginp-src-v0.21.tgz and a ginp.war file. > > We want to go for the simplest possible install. It's ok to make > developers and those who want to build it themselves do a little more > work. However, regular users, who may not even know Java, who just > want to download it and get the app to work should just be given a > single bundled war to download so that they can copy ginp.war into the > war dir and have it work without having to be aware of classpaths, > etc. 8 megs is not a lot these days. I think that we are done > growing for a while unless we add a db persistance layer. If we split it it will be half the size (~4 MB). > > I fixed the '+' encoding bug... the right way. I strongly > recommend we do a 0.21 release before people hand out lots of > permalinks using your custom encoding. Using the standard encoder is more elegant than my encoding. I was confused because the links were passed through an encoder but it did not do the + char. I can confirm that it works with my test files with funny names. The German Chars do not work. I tried changing the URLDecoder.decode(parameterValue,"UTF-8"); methods to ISO-8859-1 but it did not help. > > Glad to hear that we have a user! Remember, we have to think that > people are going to download ginp and expect to be able to figure out > how it works in 15 minutes or they are going to dump it and go onto > the next project. We need to make all this work as simply as possible! What are your thoughts on changing page 4 of the set up wizard to a "Congratulations click here to go to the home page" We change the home page to be a bit more sexy and/or clearer. We drop the select a style per collection option. This makes it clearer, and simpler. We could also use the style of the home page for the wizard so it looks more like part of the delivered application rather than an add on. You mention db. What are your thoughts on this? I want to avoid a db because it is something else to set up and it makes moving pictures complex. I like the idea of using a file manager for managing files. A desktop program like gimp for editing pictures and a web application for presenting them. I think that if the data is on the disk with the picture it is easy to move it with the picture file. I also think that the XML data can be parsed and an made into an in-memory searchable index. However searching and sorting data is a job for a database. What do you think? I will try to get 0.21 out soon. > > Cheers, > > Justin > > > Doug Culnane wrote: > >> Dear Justin, >> >> The file version 0.2 is released. It is huge and I think I need to >> split the releases into war src and lib. Or have some other >> system... Got any ideas? >> >> I fixed the + char file name bug. It is not very elegant but it >> works and should be robust. If other chars cause problems we can add >> then to the StringTool function. I can get the German chars to work >> the "äöüÄÖÜß" I do not know why but non ASCII chars are a problem. >> >> I moved the resource Bundles because it is now easier to merge src >> trees. Hope this is OK. >> >> We have a user! >> From the web stats of the ginp site I found a link from this site: >> http://www.jimmynails.com/ >> >> >> All the best, >> >> Doug >> > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > Ginp-developers mailing list > Gin...@li... > https://lists.sourceforge.net/lists/listinfo/ginp-developers > -- Doug Culnane do...@cu... www.culnane.net |
|
From: Justin <ju...@sq...> - 2005-01-21 04:05:07
|
Doug, Split the distribution into a src and war distribution but don't make=20 people have to download both the war and the lib to run ginp. We want to go for the simplest possible install. It's ok to make=20 developers and those who want to build it themselves do a little more=20 work. However, regular users, who may not even know Java, who just want=20 to download it and get the app to work should just be given a single=20 bundled war to download so that they can copy ginp.war into the war dir=20 and have it work without having to be aware of classpaths, etc. 8 megs=20 is not a lot these days. I think that we are done growing for a while=20 unless we add a db persistance layer. I fixed the '+' encoding bug... the right way. I strongly recommend we=20 do a 0.21 release before people hand out lots of permalinks using your=20 custom encoding. Glad to hear that we have a user! Remember, we have to think that=20 people are going to download ginp and expect to be able to figure out=20 how it works in 15 minutes or they are going to dump it and go onto the=20 next project. We need to make all this work as simply as possible! Cheers, Justin Doug Culnane wrote: > Dear Justin, >=20 > The file version 0.2 is released. It is huge and I think I need to=20 > split the releases into war src and lib. Or have some other system... = =20 > Got any ideas? >=20 > I fixed the + char file name bug. It is not very elegant but it works=20 > and should be robust. If other chars cause problems we can add then to= =20 > the StringTool function. I can get the German chars to work the=20 > "=E4=F6=FC=C4=D6=DC=DF" I do not know why but non ASCII chars are a pro= blem. >=20 > I moved the resource Bundles because it is now easier to merge src=20 > trees. Hope this is OK. >=20 > We have a user! > From the web stats of the ginp site I found a link from this site: > http://www.jimmynails.com/ >=20 >=20 > All the best, >=20 > Doug >=20 |
|
From: Doug C. <do...@cu...> - 2005-01-20 20:36:50
|
Dear Justin, The file version 0.2 is released. It is huge and I think I need to split the releases into war src and lib. Or have some other system... Got any ideas? I fixed the + char file name bug. It is not very elegant but it works and should be robust. If other chars cause problems we can add then to the StringTool function. I can get the German chars to work the "äöüÄÖÜß" I do not know why but non ASCII chars are a problem. I moved the resource Bundles because it is now easier to merge src trees. Hope this is OK. We have a user! From the web stats of the ginp site I found a link from this site: http://www.jimmynails.com/ All the best, Doug -- Doug Culnane do...@cu... www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-17 17:24:07
|
Dear Justin, Exactly this bug in listed in my ToDo list (ginp/docs/ToDo.txt). I will try ToDo something about it. It should not be too hard to fix so I will try to have a hack at it before release. I have a busy week this week but I will try to do a release. If you want to add to the Release notes in the ginp/docs please do. I use this text as the real release notes. All the best, Doug Justin wrote: > Doug, > > There are still some encoding problems for some filenames that will > probably start showing up more with non roman character sets. I have > files with pluses in them and files with pluses and spaces that don't > show up correctly all the time. To reproduce the bug, try creating a > picture with a '+' and a space and one with just a '+' in the file > name and make sure ginp displays the preview and picture correctly. > > On Fri, 14 Jan 2005 11:05, Doug Culnane wrote: > >> Is there any reason why I should not release 0.2 yet? >> >> I would like to do some more testing but it all seems to work very >> well (if I do not do a silly mistake). I added lots of log >> statements for error catching but its all seams fine. Therefore I >> think I will release as soon as I have time next week. >> >> I have been learning about common-logging and it is very cool >> (although the documentation seams to be work in progress...) so I >> have implemented it in my code. >> >> I have been learning about XML Schema and they are very cool and I >> want to get cleaver with this stuff so that we can use the parsers >> etc... to do lots of work for us. You mentioned XML Schema and lack >> of a permanent URL but we have >> http://ginp.sourceforge.net/XML/ginpfolder-v1.xsd for example. I >> have to learn more and do more experimentation and will post some >> proposals for your input. As I tensioned we should get this right >> because it is important. >> >> Got to go, >> >> Doug >> >> >> Justin wrote: >> >>> Doug, >>> >>> I checked in some security and bug fixes for the setup. >>> >>> Regards, >>> >>> Justin >>> >>> Doug Culnane wrote: >>> >>>> The big bug has been fixed. It was a silly mistake.... Will check >>>> in some fixes soon. >>>> >>> >>> >>> >>> >>> ------------------------------------------------------- >>> The SF.Net email is sponsored by: Beat the post-holiday blues >>> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >>> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt >>> _______________________________________________ >>> Ginp-developers mailing list >>> Gin...@li... >>> https://lists.sourceforge.net/lists/listinfo/ginp-developers >>> >> >> >> -- >> Doug Culnane >> do...@cu... >> www.culnane.net > > -- Doug Culnane do...@cu... www.culnane.net |
|
From: Justin <ju...@ww...> - 2005-01-15 00:37:29
|
Doug, There are still some encoding problems for some filenames that will probably start showing up more with non roman character sets. I have files with pluses in them and files with pluses and spaces that don't show up correctly all the time. To reproduce the bug, try creating a picture with a '+' and a space and one with just a '+' in the file name and make sure ginp displays the preview and picture correctly. On Fri, 14 Jan 2005 11:05, Doug Culnane wrote: > Is there any reason why I should not release 0.2 yet? > > I would like to do some more testing but it all seems to work very well > (if I do not do a silly mistake). I added lots of log statements for > error catching but its all seams fine. Therefore I think I will > release as soon as I have time next week. > > I have been learning about common-logging and it is very cool (although > the documentation seams to be work in progress...) so I have > implemented it in my code. > > I have been learning about XML Schema and they are very cool and I want > to get cleaver with this stuff so that we can use the parsers etc... to > do lots of work for us. You mentioned XML Schema and lack of a > permanent URL but we have > http://ginp.sourceforge.net/XML/ginpfolder-v1.xsd for example. I have > to learn more and do more experimentation and will post some proposals > for your input. As I tensioned we should get this right because it is > important. > > Got to go, > > Doug > > > Justin wrote: > >> Doug, >> >> I checked in some security and bug fixes for the setup. >> >> Regards, >> >> Justin >> >> Doug Culnane wrote: >> >>> The big bug has been fixed. It was a silly mistake.... Will check >>> in some fixes soon. >>> >> >> >> >> >> ------------------------------------------------------- >> The SF.Net email is sponsored by: Beat the post-holiday blues >> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt >> _______________________________________________ >> Ginp-developers mailing list >> Gin...@li... >> https://lists.sourceforge.net/lists/listinfo/ginp-developers >> > > > -- > Doug Culnane > do...@cu... > www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-14 14:53:35
|
Is there any reason why I should not release 0.2 yet? I would like to do some more testing but it all seems to work very well (if I do not do a silly mistake). I added lots of log statements for error catching but its all seams fine. Therefore I think I will release as soon as I have time next week. I have been learning about common-logging and it is very cool (although the documentation seams to be work in progress...) so I have implemented it in my code. I have been learning about XML Schema and they are very cool and I want to get cleaver with this stuff so that we can use the parsers etc... to do lots of work for us. You mentioned XML Schema and lack of a permanent URL but we have http://ginp.sourceforge.net/XML/ginpfolder-v1.xsd for example. I have to learn more and do more experimentation and will post some proposals for your input. As I tensioned we should get this right because it is important. Got to go, Doug Justin wrote: > Doug, > > I checked in some security and bug fixes for the setup. > > Regards, > > Justin > > Doug Culnane wrote: > >> The big bug has been fixed. It was a silly mistake.... Will check >> in some fixes soon. >> > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Ginp-developers mailing list > Gin...@li... > https://lists.sourceforge.net/lists/listinfo/ginp-developers > -- Doug Culnane do...@cu... www.culnane.net |
|
From: Justin <ju...@sq...> - 2005-01-14 11:55:53
|
Doug, I checked in some security and bug fixes for the setup. Regards, Justin Doug Culnane wrote: > The big bug has been fixed. It was a silly mistake.... Will check in > some fixes soon. > |
|
From: Doug C. <do...@cu...> - 2005-01-11 15:12:34
|
The big bug has been fixed. It was a silly mistake.... Will check in some fixes soon. -- Doug Culnane do...@cu... www.culnane.net |
|
From: Doug C. <do...@cu...> - 2005-01-10 17:49:26
|
I have updated the website. I have the following big bug. I think we
need some testing and fixing time because getting this to work is not
easy at the moment. I think this bug may be a Tomcat bug but I am not
sure. I will try to fix this but If you have any ideas please share them.
Thanks,
Doug
Debug info for Developers
org.apache.jasper.JasperException: String index out of range: 4
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:254)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356)
at net.sf.ginp.GinpServlet.doHttpMethod(GinpServlet.java:159)
at net.sf.ginp.GinpServlet.doGet(GinpServlet.java:61)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:594)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)
Model State
name: Int. Moth Photos
root: /usr2/apache/www.culnane.net/Photos/Demo
path: /
pageHeight :500
pageWidth :600
thumbMaxSize :200
pageOffset :0
pagePosition :0
userName :anon
Apache Tomcat/4.1.24 1.4.1_02-b06 Sun Microsystems Inc. Linux
2.4.20-4GB-athlon i386
--
Doug Culnane
do...@cu...
www.culnane.net
|
533 messages has been excluded from this view by a project administrator.
