The foswiki svn repository will become read-only on Friday 8/8. Developers should register for a http://github.com/ account for commit access to foswiki.

Item572: Issues with afterAttachmentSaveHander API

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Enhancement Closed Engine Plugin API  
Issues with afterAttachmentSaveHander API

I have encountered several issues with the afterAttachmentSaveHander API. We need to decide how to resolve them. Background: I am developing a plugin that wants to save a companion attachment. It's not possible with the current API. See Store.pm.

In this case, when an image is saved, I want to generate and save a companion thumbnail. I want this to happen automagically whenever an attachment is saved, transparently to the user. (Except that the user gets to use the thumbnail!)

Secondarily, I want default links to images to display the thumbnail, but link to the large image. Issues

  • the afterSave handler is called holding the topic lock. So any attempt to call saveAttachment recursively will deadlock.
  • saveAttachment closes the temporary file that (may have) used to hold the data just before calling the handler. This guarantees that the handle must reread the data all the way from the repository. This is unfortunate - on performance and atomicity grounds.
  • saveAttachment does not pass the new attachment's metadata to the handler - and it hasn't written the topic text back yet either. So the handler really can't know what it's doing.
  • there is no hook for the createlink option. It would be useful to be able to modify the returned link to meet coding or functional requirements. For example, to use %ATTACHMENT% or otherwise use an image in the link. (You may have seen the AttachLinkPlugin? appear...I suspect that Attach.pm could export some useful methods for it and the ImgPlugin? , but I digress.)

Options

  • Implement a postAttachmentSaveHander callback - right at the final } of saveAttachment. It should pass everyting it knows.
  • Provide an "already locked" flag to saveAttachment for recursive handlers - this would prevent the deadlock. But the handler would need the open topic.
  • Move the tempfile unlink down to after the if( haveHanderlFor ) block.
  • Fill in %attrs before calling the handler, and pass them along.
  • Do something really different.
  • I can do something local - the prototype simply writes directly to pub/web/topic/file

Thoughts? Takers?

-- Contributors: TimotheLitt - 21 Dec 2008

This API was deprecated in favour of the afterUploadHandler, but there is a risk that this new API may have inherited some of the issues described here, so raising from 'Enhancement' to 'Urgent' as the API must be reviewed before 1.1 is released.

  • locking - looks OK to me
  • new handlers use streams, and should not close streams (as documented)
  • meta is now passed
  • createlink is not supported - the handler is called far too late for that.

Marking as releaseable. There is still scope for improvements, but they should go through the feature proposal process.

-- CrawfordCurrie - 12 Jul 2010

ItemTemplate edit

Summary Issues with afterAttachmentSaveHander API
ReportedBy Foswiki:Main.EugenMayer
Codebase
SVN Range TWiki-4.2.3, Wed, 06 Aug 2008, build 17396
AppliesTo Engine
Component Plugin API
Priority Enhancement
CurrentState Closed
WaitingFor
Checkins
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r4 - 04 Oct 2010, KennethLavrsen
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License