What is primitiveDropRequestFileHandle and do we really need it?

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.

Hi Vanessa,

thanks for the pointer to capability-based security, this makes sense! However in the OSVM source, I could not find any implementation of dropRequestFileHandle() that would not call dropRequestFileName() and sqFileOpen(), so I believe capability-based security is not actually used at the moment. Still, this hook could be relevant when a new platform (for instance, Android?) would be supported by OSVM. So for now, I conclude that one should indeed use both primitives as implemented in the latest Trunk, in order not to comprise this possibility for future implementations.

Best,

Christoph