[Seaside] Pharo 2.0 scriptaculous does not work

Sat Jun 15 19:38:16 UTC 2013

Dale,

I guess the case was #1.
Zinc produced a new #stable version but the Seaside project referenced an older (incompatible) Zinc-Seaside package. In contrast, the Zinc project was offering a correct version of Zinc-Seaside in its #stable version, but Seaside references Zinc-Seaside using an explicit package version. 

So, my reasoning was that if Zinc was actually offering a matching Zinc-Seaside package version, it should be possible for Seaside to pick it up....

I fully agree that, given the dependencies, the Zinc-Seaside version to use should be specified by the Seaside version. But, since Seaside references Zinc using #stable, then it should also reference Zinc-Seaside using #stable. Or Seaside should reference Zinc using an explicit version.

In my mind, Zinc-Seaside is more of a shared package between Seaside and Zinc. Changes to both Seaside and Zinc might require it to be changed.
In essence, if Zinc-Seaside would really have been owned by the Seaside project, then we would have needed to adapt it to work with the new Zinc. 

Perhaps the most reasonable solution is to move Zinc-Seaside in its own configuration. Especially since Zinc is moving way faster than Seaside, we might want to deal with changing versions in a separate configuration and reference that one from Seaside using #stable.

Johan

On 15 Jun 2013, at 20:49, "Dale K. Henrichs" <dale.henrichs at gemtalksystems.com> wrote:

> Johan,
> 
> Sorry I've been completely absorbed by STIC this week, so the doctor has not been in, but he is now:)
> 
> 
> If I understand the flow of the conversation you are trying to include the Zinc-Seaside package in the Zinc project without specifying a proper dependency (because doing so would instroduce a circularity between Seaside and Zinc).
> 
> You are taking this approach because you ran into problems when Zven made a certain set of changes to Zinc that broke the adaptor...
> 
> First I'd like to back up and say the Zinc-Seaside package _should_ be included in Seaside30 project with a dependency upon the Zinc project. The Zinc-Seaside _is_ in support of the Seaside project - the code is wrapping Zinc functionality with a Seaside-specific (common) API for web servers. 
> 
> It's not correct to expect Sven to be responsible for ensuring that Zinc-Seaside passes all of it's tests whenever he releases a new version of Zinc, so he should not be responsible for the Zinc-Seaside package.
> 
> AFAICT, the issues came up when Sven released a new #stable version of Zinc that,to quote Sven:
> 
>  "Some recent changes to Zinc apparently resulted in some 
>   compatibility problems with Seaside. We fixed already at 
>   least one of them..."
> 
> Either the "recent changes" were changes to the basic API (case #1) or the Zinc-Seaside code itself was reaching into Zinc and using a private API (case #2) or the Zinc-Seaside code was written to work around/rely on a bug in Zinc (case #3).
> 
> Let's skip case #1 for now.
> 
> If the root cause is case #2, then the Seaside folks should work with Zinc to define a public API that can be safely cause across all future bugfixes ...
> 
> If the root cause is case #3 then the Seaside folks can take out there workaround and move forward. 
> 
> In both of the above cases the root cause is an anomaly that is not expected to occur _every time Zinc is updated_.
> 
> If the root cause is case #1, then we have a more difficult situation because in reality an API change results in the creation of two #stable versions ... One #stable version is Zinc with the old API the other #stable vesion is Zinc with new API.
> 
> If one expects to use a project in production applications, it is reasonable to expect that the API itself remains consistent across bug fixes ... I do not want to have to change my application in order to safely pick up a bugfix from a project ... On the other hand if I want to take advantage of the new api, I am be willing to rewrite my application to take advantage of the new capabilities... If we are indeed entering this area then we need to adpopt the Sematic Versioning Spec[1] for version naming so that API transitions can be recognized at the version-level which then makes it possible specify project dependencies in tools such as Metacello.
> 
> There is a fourth case (case #4) that occurs to me and that is that the Zinc API is not complete and Seaside is dependent upon a project with an API that is still under development. If this is the case, it behooves Sven to pre-announce his plan to change the Zinc API in an upcoming release and give projects and production apps that depend Zinc a chance to evaluate the implications and adjust their applications/dependencies in anticipation of the change...
> 
> I am not "picking on Zinc." Sven is providing a very good product free of charge to the community.
> 
> I _do_ want to make sure that we have characterized the problem completely before taking action in the form of adding features to Metacello:)
> 
> Dale
> 
> [1] http://semver.org/
> 
> ----- Original Message -----
> | From: "Johan Brichau" <johan at inceptive.be>
> | To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
> | Sent: Saturday, June 8, 2013 1:11:52 AM
> | Subject: Re: [Seaside] Pharo 2.0 scriptaculous does not work
> | 
> | I think I need the metacello doctor to work out what I had in mind.
> | Dale? you there? :-)
> | 
> | In the meantime, I bumped a new version that references the correct
> | Zinc-Seaside package version, such that it works correctly for now.
> | 
> | The problem I have is that Metacello does not support the #requires:
> | condition for project references. Before loading Zinc (with
> | Zinc-Seaside), the Seaside-Core package needs to be loaded.
> | I was under the false impression that such a statement was possible
> | in Metacello, but alas... I am wrong.
> | 
> | So now I need to figure out how we can:
> | - let the Zinc-Seaside package version be controlled by the Zinc
> | project (it makes more sense)
> | - have the Seaside config reference the Zinc project but only load it
> | after having loaded Seaside-Core.
> | 
> | I tried several things yesterday including referencing Seaside from
> | Zinc as well, but that went into an infinite loop (metacello does
> | not detect loops?).
> | Guess I was a bit too bold yesterday, but maybe Dale can shed some
> | light on how to accomplish the above two items?
> | 
> | Johan
> | 
> | On 07 Jun 2013, at 16:43, Johan Brichau <johan at inceptive.be> wrote:
> | 
> | > Thanks Sven.
> | > 
> | > I'm adapting the Seaside config to include that group instead of
> | > the Zinc-Seaside package.
> | > 
> | > On 07 Jun 2013, at 14:17, Sven Van Caekenberghe <sven at stfx.eu>
> | > wrote:
> | > 
> | >> Johan,
> | >> 
> | >> On 07 Jun 2013, at 10:11, Johan Brichau <johan at inceptive.be>
> | >> wrote:
> | >> 
> | >>> On 07 Jun 2013, at 10:03, Sven Van Caekenberghe <sven at stfx.eu>
> | >>> wrote:
> | >>> 
> | >>>> I am willing to do that (it sounds logical), but can that be
> | >>>> done without depending on Seaside itself ? Because that does
> | >>>> not sound practical, maybe reducing a circular dependency or at
> | >>>> least an interference with the specific Seaside versions and
> | >>>> groups that you initially want to load.
> | >>> 
> | >>> If I am correct, that should not be a problem.
> | >>> 
> | >>> The Seaside30 config can specify to load the 'Zinc-Seaside'
> | >>> version as specified by the Zinc config.
> | >>> All you have to do is list the Zinc-Seaside package in your
> | >>> version methods and make sure that it does not get loaded when
> | >>> not explicitly asking for it.
> | >>> I believe that can be done by not putting it in the #default load
> | >>> group.
> | >> 
> | >> I just created
> | >> ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.49 which
> | >> now has a 'Seaside' group that loads the 'Zinc-Seaside' adaptor
> | >> package with a specific version. It is of course not loaded by
> | >> default.
> | >> 
> | >>> If you want your config to be complete, you can list a dependency
> | >>> on the Seaside project for the Zinc-Seaside package. This would
> | >>> only be loaded if somebody explicitly load the Zinc-Seaside
> | >>> package.
> | >> 
> | >> For now I skipped the dependency on Seaside, we'll see how it
> | >> goes.
> | >> 
> | >> Sven
> | >> 
> | >>> If that does not work, we need to ask the Metacello doctor ;-)
> | >>> 
> | >>> Johan_______________________________________________
> | >>> seaside mailing list
> | >>> seaside at lists.squeakfoundation.org
> | >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> | >> 
> | >> --
> | >> Sven Van Caekenberghe
> | >> Proudly supporting Pharo
> | >> http://pharo.org
> | >> http://association.pharo.org
> | >> http://consortium.pharo.org
> | >> 
> | >> 
> | >> 
> | >> 
> | >> _______________________________________________
> | >> seaside mailing list
> | >> seaside at lists.squeakfoundation.org
> | >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> | > 
> | > _______________________________________________
> | > seaside mailing list
> | > seaside at lists.squeakfoundation.org
> | > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> | 
> | _______________________________________________
> | seaside mailing list
> | seaside at lists.squeakfoundation.org
> | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> | 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside