I’ve just had to fix up some code that handled file drops. Since it was easy to mooch off the code in PasteUpMorph, that’s what I did - but I’m wondering what the reason is for the rather convoluted code in StandardFileStream class>requestDropStream:
So far as I can tell the DropPlugin code provides a string representing the dropped file (along with the event carrying the number of files dropped etc) and then we immediately ask the plugin for an actual file handle. It’s a bit hard to see why the plugin needs to do that since we can open a file easily enough in other ways. I can see from the *nix and Mac OS code that they are just opening files ‘normally’ (and I agree with Ian’s comment /* you cannot be serious? */ by the way). The win32 code is less intelligible but seems to be doing much the same. Does anyone remember why we ended up going to this trouble to do something the hard way instead of passing the client a filename? The code in ExternalDropHandler spends much of its time dealing with the filename anyway. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- HARLEZ-VOUS FRANCAIS? - Can you drive a French motorcycle? |
On 10.04.2014, at 17:57, tim Rowledge <[hidden email]> wrote: > I’ve just had to fix up some code that handled file drops. Since it was easy to mooch off the code in PasteUpMorph, that’s what I did - but I’m wondering what the reason is for the rather convoluted code in StandardFileStream class>requestDropStream: > > So far as I can tell the DropPlugin code provides a string representing the dropped file (along with the event carrying the number of files dropped etc) and then we immediately ask the plugin for an actual file handle. It’s a bit hard to see why the plugin needs to do that since we can open a file easily enough in other ways. I can see from the *nix and Mac OS code that they are just opening files ‘normally’ (and I agree with Ian’s comment /* you cannot be serious? */ by the way). The win32 code is less intelligible but seems to be doing much the same. Does anyone remember why we ended up going to this trouble to do something the hard way instead of passing the client a filename? The code in ExternalDropHandler spends much of its time dealing with the filename anyway. I don't quite remember, but is it possible that dropped files might indeed need special handling in some cases? Like, if the OS gives you a handle to the file instead of just a file name. This does make sense when you think of the handle as a capability (as in capability-based security). Also, I do remember a case on Linux where we needed to delete a dropped file immediately after opening it because it was supposed to be temporary (and reading works fine even after the dir entry has been deleted). But that may be unrelated to the DropPlugin code. - Bert - smime.p7s (5K) Download Attachment |
On 11-04-2014, at 7:18 AM, Bert Freudenberg <[hidden email]> wrote: > > On 10.04.2014, at 17:57, tim Rowledge <[hidden email]> wrote: > >> I’ve just had to fix up some code that handled file drops. Since it was easy to mooch off the code in PasteUpMorph, that’s what I did - but I’m wondering what the reason is for the rather convoluted code in StandardFileStream class>requestDropStream: >> >> So far as I can tell the DropPlugin code provides a string representing the dropped file (along with the event carrying the number of files dropped etc) and then we immediately ask the plugin for an actual file handle. It’s a bit hard to see why the plugin needs to do that since we can open a file easily enough in other ways. I can see from the *nix and Mac OS code that they are just opening files ‘normally’ (and I agree with Ian’s comment /* you cannot be serious? */ by the way). The win32 code is less intelligible but seems to be doing much the same. Does anyone remember why we ended up going to this trouble to do something the hard way instead of passing the client a filename? The code in ExternalDropHandler spends much of its time dealing with the filename anyway. > > I don't quite remember, but is it possible that dropped files might indeed need special handling in some cases? Like, if the OS gives you a handle to the file instead of just a file name. This does make sense when you think of the handle as a capability (as in capability-based security). I thought that might have been the issue, but I can’t see anything in the plugin code that really supports the theory. I wondered if may it had been a Mac thing - they (used to) have some pretty weird file related needs. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: CPE: Create Parity Error |
The OLPC had quite a tricky file security system that gave you convoluted code. I think that is some of the reason this code is there. Karl On Fri, Apr 11, 2014 at 8:25 PM, tim Rowledge <[hidden email]> wrote:
|
That's what I thought at first, but I think the DropPlugin code is much older. On 11.04.2014, at 13:47, karl ramberg <[hidden email]> wrote:
smime.p7s (5K) Download Attachment |
Free forum by Nabble | Edit this page |