All you need to control the hashtable size (actually DB) is delete every so often. But on the other hand I have a record for each showing anyway, so it's not introducing a new level of scale to the db.
<div>-------- Original message --------</div><div>From: "André Warnier (tomcat)" <a...@ice-sa.com> </div><div>Date:10/02/2015 8:26 AM (GMT-08:00) </div><div>To: users@tomcat.apache.org </div><div>Subject: Re: loading images through a Servlet </div><div> </div>On 02.10.2015 17:04, Christopher Schultz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > André, > > On 10/2/15 10:38 AM, André Warnier (tomcat) wrote: >> Chris, you're kind of breaking down an open door here. Bill was >> already at the stage of congratulating himself and dreaming of his >> retirement plan, following his discovery of a brilliant and >> innovative solution. Better to start from the beginning of the >> thread.. > > Yep, I read the whole thread. > > I don't think this is a million-dollar idea. If it was, I would never > have gone to college, having written one of these for a client while I > was in high school. In my case, it was a CGI that counted hits to an > image whilst simultaneously serving that image. No security or > anything like that, but the "security" in Bill's case is just a proxy > for "do something first, then serve an image". > It is a bit more than that, though : a user cannot, for example, save the html page containing the images, and then reload it later, and still see get the images with the same image links, because they will have "expired". Neither can one of these image links simply be copied to a friend in an email, and still work for the friend. He also gets a specific action triggered when someone attempts this. It is not something infinitely scaleable (the server-side hashtable would get quite large), but it is a relatively simple scheme, usable in quite a number of scenarios. > I'm suggesting that Bill can focus on his "do something first" task > and delegate the serving of bytes to a tool more appropriate for the > task: the DefaultServlet. > I would agree with you, except that at some point Bill mentioned serving the image content out of a database blob. That's something the Default Servlet couldn't do. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
