search

webgme / bindings

WebGME API bindings for Python
MIT License
1 stars 4 forks source link

Should `get_bin_file` in PluginBase always decode base64? #25

Open umesh-timalsina opened 3 years ago

umesh-timalsina commented 3 years ago

While the get_bin_file shown below decodes a binary treating it as a base64 encoded string, it might not always be the case. Specifically, if the artifiact is loaded from elsewhere (like type: asset) from the plugin metadata? Or any artifact from the BlobClient.
https://github.com/webgme/bindings/blob/95cd3b8fc4fd7bf383a6d6fcc0a15928c634915f/python/webgme_bindings/webgme_bindings/pluginbase.py#L181-L194

kecso commented 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.