MDSplus
Provide APD access over thin client
Rebased on Alpha, introduces the management of APD access over thin client for python. Checked also against older mdsip servers.
Is this not already handled by getObject https://github.com/MDSplus/mdsplus/blob/ad08c9cc7c88f7eed946bf06f2bd6a90e2e1a25f/python/MDSplus/connection.py#L321
getObject() forces serialization/deserialization. get() and put() are more general and apply serialization only when required, and transparently to the user, keeping at the same time compatibility with the old mdsip servers and presenting the same interface and semantic of C++ and Java (they do not have getObject()).
why not adding a putObject() which would do serialization under the hood instead of tempering with get and put
something like:
self.get("TreePut($, `serializein($))", node, data.serialize()) i dont see how this is less transparent.
My point is changeing get and put to do serialization by default is a big change and not transparent at all, where as explicit method getObject() and putObject() that do the same as get() and put() would get you the same functionality without changing the behavior of existing methods.
There is indeed not a real need in the python interface to change the behavior of get() and put() , being getObject() also available (unlike C++ and Java). The real need was in Java because of the use of MATLAB structured data. For me we can also keep things as they are, but we lose uniformity across different languages.
Not feasible without a big effort. The reason is that MATLAB access at TCV goes through thin client via get() and they need full support for MATLAB (arrays of) structures. Defining getObject() in Java and going through it would require deeply changing all the MATLAB and Java support. It took a lot of time have it working and sincerely I prefer rather leaving things as they are now.
Forgot to say: and in any case the equivalent of putObject is missing in the alpha version. In this branch, put() sends serialized data only if APD are present.
Sorry, things come in my mind once a time....the reason why get() performs serialization is that we may not know in advance whether the result of the expression is an APD or not. So it is not possible to know in advance whether using getObject() or get() when retrieving data in thin client
I get that .. hence you would use getObject() and putObject() for you new code but allow older software to use get() and put() as usual. In particular you should not make APD into a special case as there is a whole class of R descriptors that require serialization.. even legacy float types would require serialization if you wish to preserve the original dtype. it is only due to backward compatibility why we have this workaround. ideally we would add a getObject() putObject() to mdsipshr that would always use serialization for passed args and returned value. this way we dont need to re-implement it in all languages individually. I developed a very flexible implementation in java mdsplus-api.. the beauty. it is as well only client site. it defines helper methods that can easily wrap arbitrary user expressions with arguments into a fully serialized form. A variation of it would do good in the core c-library. it should have a signature derived from TdiExecute() however with additional context info (holding connection info and tree info).
It is a bit more complicated.....there are use cases in which the type of the data being read is not known in advance, but discovered after having been read it (e.g. when introspecting some data). This means that we don't know whether using get() or getObject() in advance. This is the reason why get() has been made in this branch general enough to be able to read any data, including APD.
After working with the internals of the python API and thin client a lot over the past few weeks, I second Timo's comments. I think we should provide new methods for accomplishing these tasks, but I don't like the idea of serializing all .get()'s and some .put()'s by default.
