In the context of "Canvas" I see the following mechanisms to serve an image:
1) The image is in an external file served by an external server. Use:
html image url: '
http://some.server/path/to/image'.
This mechanism has no effect on Seaside's dispatcher. A small variation
uses a fixed "resource base":
html image resourceUrl: 'path/relative/to/resource/base'
where the resource base is set in the configuration tool.
2) The image is in an external file to be read and served by Seaside
(via a WACachedDocumentHandler). Use:
html image fileName: 'someName.jpg' mimeType: 'image/whatever'
This mechanism adds a permanent (until "clear all caches" is invoked)
entry point to the dispatcher. The file will be read once, upon the
first request for it, and cached forever in Squeak. Incidentally it
seems like there are potential concurrency problems in the class-side
code for storing the image in the Images dictionary. Given the way
browsers load images this will probably cause problems sooner rather
than later.
3) The image is in Squeak in a form. Use
html image form: someForm
This mechanism adds a permanent (until "clear all caches" is invoked)
entry point to the dispatcher. This entry point is handled by a
WADocumentHandler which retains a reference to the form so the form's
lifetime is now the same or longer than the entry point's.
4) (missing) The image is in Squeak in the form of a byte array. Propose:
html image data: someByteArray mimeType: 'image/whatever'
This mechanism would add a permanent (until "clear all caches" is
invoked) entry point to the dispatcher. This entry point could be
handled by a WADocumentHandler which retains a reference to the form so
the form's lifetime is now the same or longer than the entry point's.
Another thing that seems to be missing is the ability to tie the
lifetime of the image's entry point to the lifetime of the session that
caused its creation. I know that ShoreComponents adds facilities to
serve images as part of the session. I'm not sure that's what I want
since it effectively serializes access to the images. Still, this
serialization is important when your image is really a proxy to an
object stored in a DB since most(all?) of the OODB clients in Squeak are
not thread safe. This seems to give rise to the following (not
completely orthogonal) concepts when serving an image:
a) Nature of the image data
a.1) External file
a.2) Form
a.3) Byte array
b) Desired lifetime of the entry point related to the image
b.1) Infinite (until caches cleared, that is)
b.2) Same as lifetime of session which created it
c) Desired access rules for the image
c.1) Image can be accessed any time
c.2) Image can only be accessed when no other request is being
processed for the session that created it or any other images created by
that session
Some combinations are currently supported, others are not. Of course
not much of this is particular to images. What the Canvas provides for
is the ability to create new entry points. We can have any kind of
content on those entry points as we like. I invite others to critique
my classification above. I think it could be turned into code but I'm
not sure that it is complete....
David
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Locked
