Michiel Meeuwissen wrote: > 1. Still triggered in Images in the same way, but the call to 'cache' > will simply not block until it is finished. It need not block, because it > does not need the byte array anyway, it only needs the new icache number. > > ImageServlet should then detect that handle is null, and block until it > is not null. (or perhaps timeout). > > 2. Not be triggered in Images, but in ImageServlet itself. The sad thing is > that the 'ckey' field as is cannnot be used for that. Easiest would be to > change the content of ckey (it should contain the actual and not the > mangled transformation template string). > > The advantage of this is that is is easy to configure that all > image-conversions must happen on a dedicated server (the server which > does ImageServlet). > > The other advantage is that you avoid producing anything what is not > really requested by some client.
Perhaps this would combine the advantages of both: 3. The creating of the icache node (without blob) still happens in the Images builder. But, mm:image does generate an URL with the template. ImageServlet only triggers the conversion, based on the template of the URL (like the proposed 'convert' option), if and only if, the corresponding icache node already exists. The filesize field could be used to detect if the handle field is already filled, to avoid unnessesary fetching of the blob in mm:image. In that way you use the URL to communicate the unmangled ckey, without opening a vulnaribility, and without stalling the response of the containing JSP, and with the option of a dedicated Image server. mm:image could simply return the icache node number when it detects that is is filled already, but that would be a detail. Michiel -- Michiel Meeuwissen mihxil' Mediacentrum 140 H'sum [] () +31 (0)35 6772979 nl_NL eo_XX en_US
