[Seaside-dev] Seaside 3.0.4 (Swazoo & Issue 629)

[Philippe Marschall]

2011/2/15 Dale Henrichs <dhenrich at vmware.com>:
> The fix for Issue 629 has broken Swazoo 2.2, so I was wondering how you'd
> like to address this:
>
>  1. add #stausCode: to Swazoo2.2 so that Swazoo2.2 and Swazoo2.3 are
>     compatible
>  2. ask Janko to make Swazoo2.3 backwards compatible with Swazoo2.2 so
>     that we don't have to hack Seaside3.0 to make Swazoo2.3 work
>  3. refactor the swazoo adaptor into two flavors: one for Swazoo2.2
>     and one for Swazoo2.3
>  4. end support for Swazoo2.2 and require a 2.3 upgrade
>
> This issue showed up for me in a GemStone sweep for sent but not implemented
> messages.
>
> Option 1 is the easiest, since we already have a pretty much
> Seaside-specific version of Swazoo2.2 that we're using: Swazoo-lr.3.
>
> Swazoo2.3 hasn't been port to GemStone yet, so Option 4 isn't an option for
> GemStone ... for GemStone, I will do Option 1, but I'm curious how you want
> the Squeak/Pharo issue handled...

For Squeak/Pharo I figured that Swazoo usage was too low to justify
any effort, nobody reported the issue, I found it myself. For Comanche
the situation is different so we have ugly hacks like
WAComancheRequestConverter >> #requestBodyFor:. For GemStone I guess
it boils down to whether you want to and have time to port Swazoo2.3
right now. If yes then I guess it's reasonable that people upgrade
Swazoo when they upgrade Seaside. If no then just make a
Seaside-Gemstone-Swazoo and add the two methods as class extensions.

Backwards compatibility is one of those things that each project has
to decide for its own and deal with the consequences. For a user
perspective you'd probably want everything the be backwards compatible
however that puts a huge burden on the project.

> Oh, one more Swazoo2.3-related issue is that the Swazoo packages do not
> conform to the Monticello naming conventions (either old or new). Here's a
> sample of the package names:
>
>  Swazoo-2.3beta2.1
>  Swazoo-2.3beta1.3
>  Swazoo-2.3beta1.2
>  Swazoo-2.3beta1
>  Swazoo-2.2
>  Swazoo-2.2beta4
>
> These packages might be a bit difficult to load with Gofer (at least using
> Gofer to calculate the "latest mcz file") - in the past I fixed Metacello so
> that this package naming convention would sort of work, but because Gofer
> choked on trying to find the latest version, I surrendered...maybe the new
> sorting algorithm will work ... I haven't had a chance to play with it...

I think writing a mail to Swazoo-devel at lists.sourceforge.net,
explaining the issue and how to fix it it probably the best solution.

Cheers
Philippe