One(?) more way to serve an image -- comments requested

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

One(?) more way to serve an image -- comments requested

cdavidshaffer
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
Reply | Threaded
Open this post in threaded view
|

RE: One(?) more way to serve an image -- comments requested

Bany, Michel
 
> 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....

Here are my comments -

You may want to have control on the actual image encoding
when the image is supplied as a Form. Currently, a Form is
always served as GIF.

You may also want to supply the file name in the response.

HTH
Michel.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: One(?) more way to serve an image -- comments requested

cdavidshaffer
Bany, Michel wrote:

>Here are my comments -
>
>You may want to have control on the actual image encoding
>when the image is supplied as a Form. Currently, a Form is
>always served as GIF.
>  
>
Good point.

In the VW port is their an internal bitmap representation that you use?
Maybe those will require some support as well.

>You may also want to supply the file name in the response.
>
>  
>
Is the only reason for this so that the browser will respond with a
reasonable name for "save image" type operations?

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

RE: One(?) more way to serve an image -- comments requested

Bany, Michel
In reply to this post by cdavidshaffer
> >You may want to have control on the actual image encoding when the
> >image is supplied as a Form. Currently, a Form is always
> served as GIF.
> >  
> >
> Good point.
>
> In the VW port is their an internal bitmap representation
> that you use?
> Maybe those will require some support as well.

As far as I know, there is only support for GIF in VisualWorks.
Time to extend that ?
 
> >You may also want to supply the file name in the response.
> >
> Is the only reason for this so that the browser will respond
> with a reasonable name for "save image" type operations?

That's one reason. I'm actually only looking for completeness.

In the 2.6b1 branch, there is

html image fileName: 'someName.whatever' mimeType: 'image/whatever'
document: someFormOrByteArray

that matches a similar method in the classic renderer.

Michel.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: One(?) more way to serve an image -- comments requested

cdavidshaffer
Bany, Michel wrote:

>That's one reason. I'm actually only looking for completeness.
>
>In the 2.6b1 branch, there is
>
>html image fileName: 'someName.whatever' mimeType: 'image/whatever'
>document: someFormOrByteArray
>  
>

Is this the active branch?  I see recent publishes on both 2.6b1 and 2.6a3.

Anyway this message doesn't existing in 2.6a3 but maybe I should merge
it in rather than adding the one that I did n 2.6a3.  I'll take a look...

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside