Has anyone taken a look at porting Seaside yet?
Locked
 
|
I've been thinking that it sure would be nice to have Seaside running on Cuis but this is a big enough effort that I'd check in and see if anyone has already looked at and/or started on this?
Thanks, Phil _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
Hi Phil:
I not evaluated a Seaside port precisely because of it's size and complexity. Indeed would be a nice port to have, but a lot of work to maintain I think.
Currently we have Aida and I was starting with Iliad and HttpView2, but both are only work in progress by now. Cheeers. 2013/9/30 Phil (list) <[hidden email]> I've been thinking that it sure would be nice to have Seaside running on Cuis but this is a big enough effort that I'd check in and see if anyone has already looked at and/or started on this? _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Has anyone taken a look at porting Seaside yet?
|
|
Juan and I have talked about it before. I looked at it. We'd love to have Seaside working in Cuis, but it's *not* a small job. It's a real *big* job. But that was back when there were only two of us. If the group here really pulled together, we might be able to get it done in a reasonable amount of time.
One resource that could help (and also be greatly expanded in the process) is the Pharo compatibility layer that German has been tinkering with. If I was going to attack the problem of supporting Seaside, I'd start with getting Sport and Grease working reliably, and bake whatever was needed to make these two happy into German's compat layer. Since Seaside depends on these two packages, we're going to have to make them work anyway.
I'd advise against attempting to fork it. You may as well fork a white whale. You'll end up chasing the thing around for the rest of your life:)
Is anyone here active on the Seaside list? We'd almost certainly need *someone* to be there (and probably at least one head paying attention to the Pharo list) in order to succeed. On Mon, Sep 30, 2013 at 3:58 PM, Germán Arduino <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Has anyone taken a look at porting Seaside yet?
|
|
I should repeat myself on this: don't try to fork it. Build a layer of indirection, a compatibility layer that maps what Seaside (and its dependencies) need to what Cuis has. Andreas put me onto this pattern around the time he released his Traits implementation...
On Mon, Sep 30, 2013 at 6:49 PM, Casey Ransberger <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Has anyone taken a look at porting Seaside yet?
|
|
Hi Folks,
I applaud and support this initiative. However, this is a bit outside my expertise, and I can't spare a significant amount of time for it. Count me as supporter. I do promise to help. And (as usual) I'm open to thinking together which incompatibilities can be better fixed by adding or modifying some protocol in Cuis, vs. including them in a compatibility layer. Cheers, Juan Vuletich On 9/30/2013 10:56 PM, Casey Ransberger wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Casey Ransberger-2
Casey,
Never underestimate the power of the fork :-) Seriously though, having ported a few packages at this point has convinced me that you will probably end up doing one of three things to achieve the port: 1) Creating a compatibility layer so complex that Cuis turns back into Squeak or Pharo as soon as any non-trivial number of packages are needed. 2) Expend the effort (could be quite significant) to get changes ported back to the core package and hope that future updates don't create more of the same sort of issue(s). 3) Fork it, changing as little as possible. The main problem I see is that without a very specific set of core classes, formal protocols, etc. Smalltalk is basically a set of moving targets consisting of a VM, language, and frameworks driven by the fashion of the day. For things like Grease and Sport, it makes sense to try to get changes backported since that is the reason those packages exist, for a subset of functionality. For everything else, I'm skeptical that anything short of a fork will work for very long vs. the amount of effort involved. Thanks, Phil On Sep 30, 2013, at 9:56 PM, Casey Ransberger wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |