Azure-iot-sdk-c: Need support to use the Set Blob Metadata operation.

[GeraldSchmitt]

Hi,

We need support to use the Set Blob Metadata operation with this SDK.

We could use an API similar to this one:

IOTHUB_CLIENT_RESULT IoTHubClient_SetBlobMetadata(
    IOTHUB_CLIENT_HANDLE iotHubClientHandle, 
    const char* blobName, 
    const char* metadata);

Could this feature fit in the SDK?

We would be happy to contribute to this feature with a PR, if the feature is validated and an API settled down.

Cheers,

Gérald

[jspaith]

Marking as an enhancement for us to consider for future.

[GeraldSchmitt]

Hi @jspaith,

We would like to know a rough ETA of when you'll take time to consider this feature.

I understand that it's probably not the most asked feature, and even if we are ready to contribute with a PR, it still means more work for you.
The sooner we know that this feature is not likely to be accepted, or likely to be delayed, the sooner we can start working on another solution.

Cheers,

Gérald

[jspaith]

We don't have an ETA or even a yes/no decision as yet.

My concern with this one in particular is the risk - and perhaps just a risk - that the client SDK starts turning more and more into a storage SDK and gets too far afield from its core message routing roots. We understand UploadToBlob is popular and wouldn't remove it! and the multi-block is critical for mem constrained devices, but as we get more and more advanced functionality like this I start having concerns.

In a different world, the IoT SDK could just give you the connection string for the storage and there'd be a straight C API for storage operations that'd let you do all this and there'd be less coupling between them. I get we don't have this world yet and we have to ship product.

Could you let me know what alternative solution would be so we could consider various pro/cons here?

[GeraldSchmitt]

I understand your concerns.
The solution you suggest, where the IoT SDK provide the connection string for the storage, sounds like a good solution, and could suit us.
But I need to confirm this with our architect first. I'll let you know soon about our remarks if we have some.

Thanks,

Gérald

[GeraldSchmitt]

Hi @jspaith

I checked with our architect, and accessing directly to the storage with the connection string could be a good solution for us.

We could start working on a PR. All the code to get the sasuri is already in the SDK, so it should be just a matter of refactoring existing code, and provide a new API similar to this one (if I understand well your idea):

IOTHUB_CLIENT_RESULT IoTHubClient_GetBlobSasuri(
    IOTHUB_CLIENT_HANDLE iotHubClientHandle,
    const char* destinationFileName, 
    const char** sasuri);

What do you think?

[jspaith]

My apologies for the delay here. It turns out there's additional complexity and history here I wasn't fully aware of and that I'll need to further discuss with some other internal parties.

I'll try to get you an answer by end of week, but we're bumping up against architectural concerns here (especially as it can impact all SDK's since we try to maintain parity in API surface).

[jspaith]

To touch base again, we're having a discussion internally on this and may have more thinking to share in next week or so. We don't have anything firm yet but will let you know when we have a sense of direction, especially if we need further feedback.

[GeraldSchmitt]

Thanks for the update. We're waiting for more info then!

[GeraldSchmitt]

Anything new?

[jspaith]

Not at present and I'm afraid I don't have an ETA. We've had some internal discussions, but this issue has implications for the correct IoT vs Azure Storage SDK boundary and coupling between them so is fairly broad.

[zvrba]

Wouldn't adding support for returning the storage sas uri also solve #321? That way anyone can continue using the BLOB storage API after they've received the sas uri? I was about to start digging into the IoTHub SDK source to see how it obtains the SAS URI so that I can use BLOBs with the BLOB API. In the worst case, I'd be doing a REST call to this: https://docs.microsoft.com/en-us/rest/api/iothub/httpruntime/createfileuploadsasuri

(I also need to be able to resume an upload because I'll be uploading media files from devices with unstable net connectivity.)

[jspaith]

Yes, getting the uri would get the IoT SDK out of this business and be cleaner architecturally.

Just to let you all know where we're coming from... the C SDK is already quite serious about not breaking the API (or when we do it'll be a VERY big deal and happen infrequently) and getting even more so. We're hoping to add basic back-compat tests and even at some point (TBD) get ABI back-compat testing available.

This has implications for adding new API's. We don't want to do so until we're like 99% sure it's not going to need an _Ex() :). So before we plumb up even a string - this string specifically - we're going to be very thoughtful in how we do it, what additional functionality would look like using it and how it'd related to SDK, etc.

I'm hoping in next few weeks we can get some rough agreement and once we do, we can work on plumbing up a string - even if its on your own to interact with REST for now and then we'd implement broader strategy later.

[gregman-msft]

Thank you everyone for the feedback on this issue. This will require new work on the blob storage support, which we are transitioning to a new repository. I have opened up a request on your behalf in this new repository here. Please track the request there and feel free to add any additional comments.

[az-iot-builder-01]

@jspaith, @zvrba, @gregman-msft, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey