Hi all,


as some of you already might have noticed [1, 2], I am currently working at a more powerful Drag and Drop (DnD) handling at the VM level of Squeak, heavily inspired by Marcel's ideas. While studying the existing source code, I was wondering what is the actual purpose of primitiveDropRequestFileHandle compared to primitiveDropRequestFileName which both are called by StandardFileStream >> #requestDropStream:.

I had a very short look at all the different DropPlugin implementations and in a nutshell, dropRequestFileHandle appears to call dropRequestFileName and then sqFileOpen() that path using the FilePlugin. Compared to this, the regular primitiveFileOpen from the FilePlugin which is called by StandardFileStream >> #open:forWrite: leads to fileOpenNamesizewritesecure() which first performs some ominous security checks (basically whether the file path is valid and the file is writable if needed) and then, again, calls sqFileOpen().


So at the end of the day, both primitives appear to call the same logic. So please allow me my naive question: Does anyone remember or imagine any good reason why we have an additional primitive for this purpose? My overall guess (from what I have learned so far about the VM side) would have been that you should be as frugal as possible when it comes to introducing a primitive, because developing, debugging, and exploring VM code is so much less simple and intuitive than Smalltalk code. For this reason, I would not expect to find any redundant "convenience primitives" in the OSVM interface.


I have two hypothetical explanations so far which however both I do not find satisfying:


  *   Optimization: Could there have been some ancient times where it might have been wise to save a redundant call to the SecurityPlugin after you have got a trusted file path from the host system?
  *   Buggy SecurityPlugin: Could there be any situation in which the SecurityPlugin would refuse a special file path returned by the DropPlugin though it can be opened by sqFileOpen()? But I cannot experience such a situation.

<http://www.hpi.de/>

Tl;dr: What is the reason for the existence of primitiveDropRequestFileHandle and should it still be used? Why not simply nuke it and always use primitiveDropRequestFileName + primitiveFileOpen? Looking forward to your suggestions!

Best,
Christoph

[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/508
[2] https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/514
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200819/ff1e037d/attachment.html>