Open umesh-timalsina opened 3 years ago
I believe it is a constraint that most people can live with, and it would make the process of dealing with binaries a lot more complex on the server side. It is the user who knows how their artifact if binary are coded. Therefore, they can convert it to the widely accepted base64 before storing it to the blob. I do not see how this could be a real limit factor, but I do see that it would be extremely hard/brittle to allow multiple encodings on the blob. On the other side of things, you cannot provide the binary for the plugin with multiple encodings either as they might not be prepared for that. So in the end it would make the plugins life harder as well. Those plugins that are connected to other functions that might dealt with other encodings will know exactly if they need to convert back the retrieved data...
So unless there is a use-case where it is impossible to change the encoding of some binary content before uploading it to the blob, I do not see why the blob should have this feature.
While the
get_bin_file
shown below decodes a binary treating it as abase64
encoded string, it might not always be the case. Specifically, if the artifiact is loaded from elsewhere (liketype: asset
) from the plugin metadata? Or any artifact from theBlobClient
.https://github.com/webgme/bindings/blob/95cd3b8fc4fd7bf383a6d6fcc0a15928c634915f/python/webgme_bindings/webgme_bindings/pluginbase.py#L181-L194