Probably an easy problem for someone...
I want to put two small images in my database and then output them in
my app, so that they do not constitute additional http requests.
Consider it an experiment - I know that it may seem a bit silly. The
goal is for the entire page to be delivered to
And the point of doing this is?
You wouldn't be saving any real bandwidth by doing it in a single request.
The size of the data is the size of the data, regardless of the number of
requests. You'd just be saving requests.
Shawn Gorrell
Web Development Applications Architect
Federal Reserve B
I believe there would still be three http requests here. The images would
still be called up in the html like right? Sorry but in http
that would still create seperate http requests.
John
[EMAIL PROTECTED]
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derrick Pea
I'm just curious. What are the benefits of storing the image in the db rather
than storing the file on the filesystem and the path in the db? I mean, for a
web page, all you need is the and the path. I can understand how it might
be useful in some VB or C or Java app where the client doesn't di
"Consider it an experiment - I know that it may seem a bit silly."
"Fennell, Mark P." <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/18/2007 10:21 AM
Please respond to
discussion@acfug.org
To
discussion@acfug.org
cc
Subject
RE: [ACFUG Discuss] Image from DB
I'm just curious. What
Honestly, there's not really a benefit per se. There might be a rare case
now and then for doing this, but really you should probably just use the
filesystem for what it's design for, storing files.
John
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fennell, Mark P.
This seems to be asked often about images and BLOBs. I know you are testing
an idea out and maybe you can get it to work somehow, but from a data
perspective you just don't want to use a BLOB. There is only one technique
to reduce up front cost of a BLOB and that is to have a BLOB table. The
ta
Kindly, and with respect to everyone that replied:
1. As I stated, the goal is to reduce http requests, not file sizes.
And "this is an experiment," please forgive, but the "Why" of why I
want to do this is not part of the answer.
2. Don't really need a discussion about the database design
Don't get me wrong, I understand it's an experiement and it's fun to try.
1. You're not actually reducing your http requests. <-- My main point with
this.
3. You can save the image data in the database as a BLOB and output it onto
a page. You'll need to use cfcontent to set the precise MIME typ
In that case, why not save the entire page html, images, etc. in the database
then use one cfquery and one cfoutput with a cfcontent type=text/html...? And
with equal respect and forgiveness, an experiment without a why or what if, is
little more than a stunt. It's usually easier to find a solut
Additionally, I think HTTP 1.1 allows connection keep-alives so that you only
make one http call for the entire page. Right?
mf
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Mason
Sent: Thursday, January 18, 2007 12:03 PM
To: discussion@acfug.org
Subj
Yes, you only need the server to run http 1.1 which most do. Also the
browser should be able to accept that (which most do) and the browser has to
not send a close command which at times they do.
A lot of things are controlled by the user in this situation. Whether
accepting a open keep-alive htt
Thank you again - everyone!
I think (by virtue of forcing the question), that the answer is that
what I want to do is not really worth it or might best be done with
the keep-alive option.
The goal, again a theoretical one, is to reduce the number of http
requests as that really is the big
On 1/18/07, Derrick Peavy <[EMAIL PROTECTED]> wrote:
Thank you again - everyone!
I think (by virtue of forcing the question), that the answer is that what
I want to do is not really worth it or might best be done with the
keep-alive option.
The goal, again a theoretical one, is to reduce the nu
Douglas, yep. You nailed it.
_
Derrick Peavy
Sales and Web Services
Universal Advertising
Phone: 404-786-5036
Fax: 404-370-0470
http://www.universaladvertising.com
http://www.collegeadvertising.com
http://www.collegeclassifieds.com
___
On Jan 18, 2007,
Right--so to be clear Derrick is looking to not use the tag but to
instead use some other mechanism such that the image isn't a separate file
that is referenced (as is the case with the tag) but is actually part
of the HTML itself. I don't know a technique for that--does anyone else?
Josh
_
Not true--there can be a benefits: data management & security. Derrick
started this whole discussion on the BlueDragon Interest list. I guess he
brought it here because no one could tell him a technique for doing what he
wanted on that list. But over there just as here, people asked the "why
wo
I agree that with strict image security it is an option. Give an image only
to particular people, etc. But data management? I don't think so, but let's
just my opinion. Image security is probably the only practical example I can
think of for doing this, but there again Derrick isn't going for that.
Let me preface this with, I know squat about the server realm. But would
Flash or an applet get you anywhere? Some sort of caching? Just throwing
some thoughts out there.
mcg
Josh Adams <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/18/2007 02:35 PM
Please respond to
discussion@acfug.
Yes and I've seen a situation where images needed security; it is due to
the site's purpose in life. *cough* Tommy *cough*
mcg
John Mason <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
01/18/2007 02:49 PM
Please respond to
discussion@acfug.org
To
discussion@acfug.org
cc
Subject
RE: [ACF
in this case I'd suggest implementing J2EE container security. You can
secure any resource this way.
DK
On 1/18/07, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
Yes and I've seen a situation where images needed security; it is due to
the site's purpose in life. *cough* Tommy *cough*
mcg
I'm doing this because
I'm forced by a legacy application to do
so, but it is a terrible strain on my CF
and my db server. Most databases simply are
not designed to efficiently handle these
long records. Apart from that, editing an
image becomes a nightmare. Security can be
handled even i
There are lots of ways to secure images that are delivered from the file
system, just as there are lots of ways to secure images delivered out of the
DB. The point is that if you're already using a security mechanism created
in CFML, then if you deliver an image (be it out of a DB or off a
non-web
Sure it's data management. You could keep text data on the file system too
but you typically don't--unless maybe it's a lot of text, right? Images are
no different--if they're not that big, why complicate matters by storing
them on the file system? You're already having to do a DB lookup to know
I beg to differ. Text
may need to be searched and edited, images
cannot (easily) be searched or edited when
placed in a db. Also, almost all my images
happen to be larger than 8k, the limit for
what fits in a record for SQL server, so
they are placed in a different area, slowing
retrieval
Just to be clear the security aspect is of no issue here. I am
not interested in doing this for security.
I agree with those who have posted about the con's of doing image
management in a DB. I don't want to do that.
What I specifically was trying to accomplish is the storage of a
fi
If you're at the point where everything else is totally optimized and
requests is the only thing left to address (and is a real issue, not a
perceived issue), then you should consider moving your images and other
static assets offsite to a provider like Akamai. Send your non-appserver
requests
Searching is a good difference to note. Editing could be as well, but the
same could be said about text data. No doubt it's something you want to be
careful about. But the point is that just as there are some reasons to
consider not storing images in a DB, there are reasons to consider doing it.
It seemed the buffer on the apache side of OC4J. After modifying that, it
seemed to work.
From: "Bryan Tidd" <[EMAIL PROTECTED]>
Reply-To: discussion@acfug.org
To: discussion
Subject: RE: [ACFUG Discuss] Prompting to download CFM files
Date: Wed, 17 Jan 2007 14:00:22 -0500
Anything interest
Scott, just curious: how did things turn out?
/Charlie
http://www.carehart.org/blog/
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Caillier
Sent: Thursday, January 11, 2007 5:33 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] cferror question
Tha
Good point. In fact, perfect point. I think if I can ever achieve
that kind of traffic, that would be the best route. Until then, I
think it's good to go. Just trying to cover all the basis before
inviting the world.
_
Derrick Peavy
Sales and Web Services
Universal Advertising
P
It's quite an interesting read on scalability and how they dealt with
it. Coldfusion mentioned.
http://www.baselinemag.com/article2/0,1540,2082921,00.asp
--
<--->
Alex Pilson
FlagShip Interactive, Inc.
[EMAIL PROTECTED]
<-
At 7:04 PM -0500 1/18/07, Alex Pilson wrote:
It's quite an interesting read on scalability and how they dealt
with it. Coldfusion mentioned.
http://www.baselinemag.com/article2/0,1540,2082921,00.asp
Oh I forgot and BlueDragon.NET!
--
<-
33 matches
Mail list logo
