[Seaside-dev] Seaisde-Filesystem-mls. *

[Michael Lucas-Smith]

Philippe Marschall wrote:
> 2009/6/4 Michael Lucas-Smith <mlucas-smith at cincom.com>:
>   
>>> I don't think we can assume that all platforms use / as a path separator
>>> ;-)
>>>
>>>
>>>       
>> I may be wrong, but I thought the method #localNameOf: converts URLs to
>> local filenames for the current platform.
>>     
>
> Uhm no, it returns the local name of a file path. Eg if the path is
> 'C:\Windows\win32.dll' and the platform is Windows the it would return
> 'win32.dll'.
>
>   
Thanks, I've updated the WAVisualWorksPlatform.
>> If not, then I guess I'd like to
>> add a "primitive" for that. That way, the WAExternalFileStream can work with
>> WAUrl right up until the very last moment it decides to talk to the file
>> system.
>>     
>
> There is no WAExternalFileStream.
>
>   
Sorry I meant WAExternalFileLibrary.
>> At least, that's what I was hoping to do.. I may have completely
>> misunderstood #localNameOf:, since it has no comment describing what it's
>> meant to achieve :)
>>     
>
> True, I'll see what I can do.
>
>   
Thanks.

I'm not 100% sure the direction I want to take Seaside-FileSystem makes 
sense for Squeak and other platforms.... but I'll throw it out here just 
in case it does.

Right now, it uses WAPlatform to find files in a directory, but it 
doesn't do the same for files.. in fact, that filesIn: assumes that the 
string is going to be in the right platform notation too, which is a bit 
of a stretch.

The response is handed a bytearray of data for the file from disk when 
it does respond with a file. This is counter to performance with 
Opentalk-HTTP, where you can simply give it a stream and let it deal 
with it. Ideally, I'd like to give Opentalk a Filename object even and 
let it decide when to open/close it and also whether or not to mmap it 
for further speed.. there are lots of options if we make fewer 
assumptions at the file library level.

Rewinding a back.. handing a stream back to the WAResponse would require 
a different protocol to #document:mimeType:fileName:.

Essentially, it would be very easy to make a VW only solution to this 
particular usage pattern, taking advantage of the Opentalk to get good 
thru-put. It would also divorce it away from Sport and make it less 
portable.

The Opentalk adaptor can accept three kinds of response bodies: String, 
Stream and Block. The block lets you programmatically stream data out 
until you're ready to finish. It's actually down at the MIME level, so 
you can stream multiple mime bodies back with a Content-Type of 
multipart. It's less constraining... however I'm pretty sure that this 
level of API isn't available for all the adaptors.

That pretty much leads me to believe that I should stop messing around 
with Phillipe's Seaside-FileSystem and make a different package to 
provide the same WAExternalFileLibrary class interface, just implemented 
very differently.

What do you think Phillipe?

Michael