Seaside-FileSystem in Seaside 3.2 ?

The Seaside-FileSystem package currently resides in the Seaside30LGPL repository.
What exactly is the reason for applying the LGPL license to this package?

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.

Opinions?

Johan_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Sat, Sep 27, 2014 at 8:03 PM, Johan Brichau <[hidden email]> 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
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On 28 Sep 2014, at 13:57, Philippe Marschall <[hidden email]> 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).

cheers
Johan_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Sun, Sep 28, 2014 at 2:09 PM, Johan Brichau <[hidden email]> wrote:
Fair enough, fine with me.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev