[Seaside-dev] Seaside-FileSystem in Seaside 3.2 ?

[Philippe Marschall]

On Sun, Sep 28, 2014 at 2:09 PM, Johan Brichau <johan at inceptive.be> wrote:
>
> On 28 Sep 2014, at 13:57, Philippe Marschall <philippe.marschall at gmail.com> wrote:
>
>>> Since I still find this package the easiest for serving external js and css files in development, I would want to include with Seaside 3.2 in the same repository.
>>> That would also mean all authors (Philippe, Julian and Lukas) have to agree with the relicensing to MIT.
>>
>> Fine with me if SPort has been relicensed.
>
> If the dependency on SPort was eliminated (which is what I did), that shouldn’t apply imho.
>
>>> Opinions?
>>
>> I think whatever we'll end up doing will suck from a maintenance point of view:
>> - We haven't had the best experience with how SPort is maintained on
>> Squeak/Pharo. If we switch to SPort I fear we may end up maintaining
>> SPort as well (see Komanche).
>
> Exactly.
> Which is why I want to eliminate this dependency and require the implementation of platform-specific methods for Seaside-FileSystem on each platform where we want to be able to use the package.
>
>> - If we add extension methods on the Grease Platform class we
>> essentially created our own file system abstraction on our god class.
>> Should we really all these things there? If we put the methods
>> somewhere there's no denying we created our own file system
>> abstraction. Is this really something we should be doing? Should we
>> have generic low level methods or very specific ones as currently used
>> by file library?
>
> I followed the approach of the file library methods: i.e. very specific ones. I also resorted to passing strings around to represent filenames, which is very inefficient (they need to be parsed a lot). However, given the purpose of the package is development support, I don’t really care. I also keep the platform-specific methods in the Seaside-FileSystem package and I propose to still carry it as an ‘add on’ package (i.e. not included in the default set of packages).
>
> All in all, I just did not want to loose the package but I did want to get rid of the Sport dependency (which is unmaintained).

Fair enough, fine with me.

Cheers
Philippe