Should get_bin_file in PluginBase always decode base64?

[umesh-timalsina]

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.

bindings/python/webgme_bindings/webgme_bindings/pluginbase.py

Lines 181 to 194 in 95cd3b8

	def get_bin_file(self, metadata_hash, sub_path = None):
	"""
	Retrieves the file from blob storage.
	:param metadata_hash: the "id" of the file to retrieve.
	:type metadata_hash: str
	:param sub_path: the path of the file to retrieve if it is inside an artifact/complex blob.
	:type sub_path: str
	:returns: The file content.
	:rtype: bytes
	:raises JSError: The result of the execution.
	"""
	content_as_string = self._send({'name': 'getBinFile', 'args': [metadata_hash, sub_path]})
	return base64.b64decode(content_as_string.encode('UTF-8'))

[kecso]

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.