Hi
On 14/01/14 21:19, Henry Clout wrote:
Hi Sergey.
Sure, so long as it's possible for the service implementation to map an
attachment to the the generated temp file, that'd work. I guess for the
particular use case I was describing it's slightly less clean, since the user
needs to take into account the fact that the data may be in memory rather than
on disk. But then having access to the file itself is more flexible.
What I've understood so far is that it is really an issue of the
temporarily files stored in the locations which make it expensive and
may be less secure to process the actual attachment stream.
So suppose we have an application code accepting InputStream
representing a given attachment part. IMHO the application code does not
need to know or deal with the temporarily file which may have or not
been created, the concern of the application is to read the available
stream; as such I'm not really keen too on Attachment offering a
transferFile operation, IMHO this is an extra concern for the
application code :-)
IMHO, offering the developers a chance to customize the way
CachedOutputStream creates temporarily files will solve the problem
under the hood, while the application code will just continue processing
InputStream the high level way...
Thanks, Sergey
Yours,
Henry
On 12 Jan 2014, at 18:19, Sergey Beryozkin <[email protected]> wrote:
Hi Henry, Dan,
Should we offer an interface for users to create a temporary file instead ?
For example, by default a temp file is created in the system temp drive,
developers can customize it by creating a temp File in the right location and
with the more user-friendly name if needed ?
Cheers. Sergey
