[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bpel4people] BP-39: Getting or deleting individual attachments
I've chosen to represent my proposal for this by including proposed
edits to the WS-HT spec (enclosed). There would also need to be a small change to the B4P spec,
which is that the third paragraph of section 3.3 should be deleted (lines 603
and 604). It currently reads: "In all cases, if several
attachments of the same name are propagated, they are combined into a list of
attachments with that name; no attachment is lost or overwritten." Michael From: Luc Clement
[mailto:luc.clement@activevos.com] FYI: I’ve annotated BP-36, 37, 38 and 39 with the notes sent by
Michael today. Luc From: Michael Rowley
[mailto:michael.rowley@activevos.com] Note from the F2F on this… We should remove getAttachments(name) and deleteAttachments(name)
and replace them with the functions that take IDs. The names of the
functions then don’t need “ByID” and can just be called getAttachment(ID) and
deleteAttachment(ID). An open question is whether Attachments should be process scoped or
task scoped, given that task infrastructure is probably what will be generating
these IDs. We considered whether there should be an update function, but
thought that delete & add might possibly be sufficient. Michael From: Luc Clement
[mailto:luc.clement@activevos.com] Assigned: http://www.osoa.org/jira/browse/BP-39
From: Michael Rowley
[mailto:michael.rowley@activevos.com] TARGET: WS-HT DESCRIPTION: Currently there are operations for getAttachments(name) and
deleteAttachment(name). These get or delete _all_ of the attachments of
the given name (names are not unique, so there may be several). It should
be possible to look at single attachment and possibly delete it, without having
to always look at and delete all the attachments that share a name. This is especially important when you have a UI that
presents a list of attachments to the user. The user should be able to
click on one and see just that attachment, or delete one, and know that only
that attachment will be deleted, even if others share the same name. PROPOSED RESOLUTION: Introduce the concept of attachment IDs. Each
attachment would have a unique ID within the process. The attachment IDs
would be returned as part of the getAttachmentInfo structure. Introduce two new operations: getAttachmentByID(attachmentID) deleteAttachmentByID(attachmentID) The addAttachment() function also needs to be changed to
return an attachment ID. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]