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

[Philippe Marschall]

On Sat, Sep 27, 2014 at 8:03 PM, Johan Brichau <johan at inceptive.be> wrote:
> The Seaside-FileSystem package currently resides in the Seaside30LGPL repository.
> What exactly is the reason for applying the LGPL license to this package?

It uses SPort which was at that point was LGPL (dunno if it was been
relicensed since).

> In addition, it depends on Sport but I now refactored it so it adds platform-specific extensions to the Grease Platform class.
> In Pharo3+, this means we can drop the loading of the FileSystem-Legacy package (which is dragged in by Sport).
> It also means every platform should be able to implement the platform-specific parts.
>
> 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.

> 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).
- 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?
- The last option would be forcing Collins file system on everyone
(and dealing with the differences between this version and the one in
Pharo).

Cheers
Philippe