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

[Philippe Marschall]

2009/6/4 Michael Lucas-Smith <mlucas-smith at cincom.com>:
> 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.

Well these messages are intended to be send from a doIt so accepting
the platform separator seems defendable ;-)

> 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.

For production use we recommend Apache. Besides the usual performance,
stability, security, log, sysadmins and all other boring reasons it
runs a different process and uses multiple processes. Since all the
Smalltalks we support are single threaded that means on a multicore or
multi CPU box you get more cycles for Smalltalk.

> 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?

Writing your own seems like the way to go. I'm not sure about the
class name though. I see two potential issues with sticking to
WAExternalFileLibrary. The first is how to keep them in sync. E.g. if
we add a feature to our WAExternalFileLibrary how does it get added
your WAExternalFileLibrary? The second is that some people might want
to use Swazoo 2 instead of OpenTalk (we had this use case a couple of
times). So I'd rather take something specific like
OpenTalkFileLibrary.

Cheers
Philippe