Re: Advice on dynamic graphics with WO
Re: Advice on dynamic graphics with WO
- Subject: Re: Advice on dynamic graphics with WO
- From: Tom Pelaia <email@hidden>
- Date: Mon, 05 Jan 2004 12:57:15 -0500
- Organization: ORNL/SNS
I don't have that code with me today, but I am not using WOImage.
Rather I am using the new file streaming APIs available under WO 5.2.2
(they may have been available in earlier 5.2 releases). I use the same
technique to stream images and other documents (e.g. pdf, txt, ...) with
the only difference being that images are displayed inline whereas
documents get downloaded to the user. I started with some code someone
sent me on this mailing list (called something like
InMemoryImageElement), but have modified it considerably since to
support streaming and also delivery of documents. I also took several
queues from Apple's FileUpload example. Since I don't have the code in
front of me I will tell you what I remember. I began by creating a
custom dynamic WO component. It uses a WOGenericComponent (I believe
that was then name) to make a custom component for links ("<a>" tag)
and images ("<img>" tag). To be clear I am talking about two separate
custom components (one for streaming documents and one for streaming
images). I set the "href" (or "src" for images) property to the
WOContext's componentActionURL which is generated dynamically. I get
the NSData for the image BLOB stored in the database and get the MIME
type for the image which is also stored in the database along with the
image. I create a stream off of the image data using the stream()
method of NSData. I then create a new response and set the content
stream to that stream and set the header information such as mime type
and the desired file name. Unfortunately IE ignores this header
information which causes problems for files that are downloaded on
Windows using IE. Other browsers, however read this header information
and handle the data properly.
This may sound confusing because I don't have the project in front of
me, but essentially those are the steps.
Jonathan Rochkind wrote:
I am curious to know what mechanism you use to actually return the
images (stored in the db) to the browser. The ordinary way to do this
in WO would be with WOImage with a 'data' binding, but there are a
variety of problems with this involving memory management. If you
haven't encountered them even if your heavily accessed app, more power
to you. But I'm curious exactly how you are deliving the images, and
if you did anything special for memory management purposes.
--Jonathan
At 8:46 AM -0500 1/2/04, Tom Pelaia wrote:
We grab images from the database in our WebObjects application
(electronic logbook). It is a very heavily accessed site and allows
users to make entries that have text, images and other attachments. We
have found additional "pros" for loading images from a database.
Additional database pros:
1) The logbook isn't the only application that uses our database. We
just use a subset of the database. Other applications write to the
database and make entries into our logbook and use data from our
logbook. Storing complete logbook entries (images, text, attachments)
in the database means other applications have easy access to logbook
entries. Hence we are integrated well.
2) The database is the one official source of all data
3) Backups are consistent and easy. When the database is backed up, all
logbook data is backed up and the backups are self consistent.
4) It is easier to transfer data from one machine to another since you
only have one thing to transfer.
5) Since the images are provided by users, the database provides a way
to avoid file names collisions. If you use a file system you need to
save filenames carefully to avoid duplication.
6) The first logbook we developed several years ago (without WO) stored
data including images in the filesystem. That turned out to be very
inflexible. If you want to reorganize the folder layout, lots of links
will break. This is simply a non-issue for database storage.
7) Databases are simply much more flexible. Filesystem storage is very
rigid. You can store your files for the present application, but needs
tend to change in time and database storage is much more flexible in
supporting future needs that you might not be considering today.
Whether you choose database storage or filesystem storage really depends
on your application. For our application, the electronic logbook is
becoming more integrated with other systems and the database has turned
out to be critical in that integration.
Subject:
Re: Advice on dynamic graphics with WO
From:
Arturo Pirez <email@hidden>
Date:
Thu, 1 Jan 2004 10:47:58 -0500
To:
Geoff Hopson <email@hidden>
My opinion and experience FWIW, having done it both ways. I keep
having this discussion so
I'd thought I'd put it all down in one place.
Database pros:
1. It's really easy.
2. It works well.
3. It's consistent with everything else; i.e. all data comes from the
database.
Database cons:
1. There are some tuning issues around BLOBs if you're using those (or
equivalent).
2. I don't understand people saying "It solves single point of
failure." Didn't you just move
the single point of failure from a file system to the database? Sure,
databases offer replication
but you can achieve the same with a clusterable file system like
Transarc or the Andrew File System (AFS).
3. It "makes no sense." It's just storing a bunch of non-relational
data in a relational database. It feels
unclean :-)
4. If you need to manipulate the data it's much much harder. For
example, if it's text and you want to
fix a typo it's problematic. If it's an image updating EXIF headers
would be a chore. It's much easier
to run a perl script over a directory of files.
Filesystem pros:
1. It scales better.
2. It's easier to manipulate the images if that's necessary.
Particularly offline from serving them.
> 3. It's cheaper. (Disks are cheaper costwise than databases esp. if
you need a DBA).
Filesystem cons:
1. It's a little harder to manage. And you might still need a
database to keep track of the images.
2. It's harder to build a content management system that can upload
images. WebDAV might address this issue.
Well, my 2 farthings.
----
WO in philadelphia - wanna cheesesteak with that?
Please visit webobjects.meetup.com.
--
Tom Pelaia
SNS Project, 701 Scarboro Road, MS-6473, Oak Ridge, TN 37830
phone: (865)574-6421, fax: (865)574-6617
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Tom Pelaia
SNS Project, 701 Scarboro Road, MS-6473, Oak Ridge, TN 37830
phone: (865)574-6421, fax: (865)574-6617
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.