Add method copy for BlobStoreDAO

[vttranlina]

related to the public Asset feature
IMO the following:

• give upload blobId + source BucketName
• fetch content from BlobStore
• push content (was fetched) to target BucketName

It does not optimize, (at least with S3BlobStoreDAO)
The S3 already supports API to copyObject (without fetch-push)
software.amazon.awssdk.services.s3.S3AsyncClient#copyObject)

Not sure if other impl of BlobStoreDAO is possible to do it or not.
If not, we can write the default implement (fetch-push)

The method looks like: public Mono<BlobId> copy(BucketName sourceBucketName, BlobId sourceBlobId, BucketName targetBucketName)

[quantranhong1999]

Sounds like a good idea to me. Maybe we can apply this for copy messages too?

[Arsnael]

Technically copy message the blob stays the same in the object storage, you don't really copy anything right? it's just in the metadata you say it belongs to multiple mailboxes?

[chibenwa]

Overall Ok to me.

But I have a question: this is linked to tmail needs but needs to land on the S3BlobStoreDAO.

How do you plan to justify such changes on james side?

[vttranlina]

I tried to find the any feature in james can reuse benefit from this api, but not found
The new API introduced has not been utilized; approval is unlikely.

[Arsnael]

Disagree. Maybe other people in the community would be interested?

And I would like to say that James is like a big toolbox, tools and methods are put for people to use or not depending on their need (tailored james mail server).

This would be just extending the s3 toolbox, allowing anybody (us included) with base james api to make a copy using native s3 api without having to do like we do actually (fetch the blob and rewrite it in an other bucket), which would be more efficient

I dont see why the community would refuse such an addition :)

[chibenwa]

Mind that alternative designs exists by uncoupling the s3Client initialization from its use in S3BlobStoreDAO.
This could be done by having a S3ClientFactory for instanciating S3CLient from the configuration.
Then we would just inject s3Client into S3BlobStoreDAO
And other use cases could inject their own s3Client to work with.
Then thanks to this simple design "toolbox users" could write whatever they want without "leaking" their use case in Apache James.
Thoughts?

[vttranlina]

looks good 👍

[chibenwa]

BTW this discussion should have had been happening on a James canal.

[vttranlina]

I emailed the mailing list https://www.mail-archive.com/[email protected]/msg74246.html