MIMEdatabase fix?

> Hi all,
>
> ok, suggestion:
> if we change Kom and Seaside to use the message contentType where they
> expect a mime type string, then it would be easy to make it work on  
> both
> Pharo and Squeak without too much trouble.
> Seaside doesn't call mimeType on many places and usage is somewhat
> inconsistent right now as in
> httpResponse contentType = aHandler mimeType
>
> Comments? Suggestions?
>
> Michael

> Lukas Renggli wrote:
>>> what seasiders think?
>>> I would be in favor to get a KOM pharo version
>>
>> Having two incompatible versions of Kom makes distribution even more
>> painful as it is today. I would prefer to have compatible versions if
>> this is possible.
>
> As I said, we are at or at least close to the point where we have to
> make the decision which version to support. If you want to have Pharo
> stay compatible with Squeak, we can just as well abandon Pharo now.
> It's as simple as that.

>
> OK, here we go...
> in the Pharo inbox there is a new version of Network-MIME and
> KomHTTPServer. The Kom package should also work on Squeak.
>
> Seaside would need to change its use of mimeType to contentType in a
> handful of places (my guess).
>
> Michael
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Philippe Marschall wrote:
>>> Newer version of MIME package plus the attached change for Seaside makes
>>> at least the tests pass.
>>
>> -1
>>
>> I don't have any interest at all to have a version of Seaside 2.8 for
>> Squeak and one for Pharo.
>
> That's what I'm currently trying to avoid,

> Philippe Marschall wrote:
>
>>> There is actually on more method (attached) that we need to add to
>>> either Kom or Seaside to make Pharo and Squeak compatible on the API level.
>> Sorry but no, see previous posts. Have a look at Seaside2.8a1-pmm.583
>> for what I would find acceptable.
>
> OK, can you explain how I should make Seaside work on both Pharo and
> Squeak? I spent two days figuring out a minimal set of changes that
> would not require doing some ugly hack testing for which underlying
> platform you are dealing with and you say that is not acceptable? You
> *want* ugly hacks? I don't understand...

> Michael Rueger wrote:
>> Michael Rueger wrote:
>>> OK, here we go...
>>> in the Pharo inbox there is a new version of Network-MIME and
>>> KomHTTPServer. The Kom package should also work on Squeak.
>>
>> ok, one more thing ;-)
>> Newer version of MIME package plus the attached change for Seaside  
>> makes
>> at least the tests pass.
>
> -1
>
> I don't have any interest at all to have a version of Seaside 2.8 for
> Squeak and one for Pharo.
>
> If you absolutely have to you can make some unholy, brittle hacks like
> we currently do for author initials to figure out if we're Squeak or
> Pharo. Maybe even an #isPharo method.
>
> Cheers
> Philippe
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Michael Rueger wrote:
>> Philippe Marschall wrote:
>>
>>>> There is actually on more method (attached) that we need to add to
>>>> either Kom or Seaside to make Pharo and Squeak compatible on the  
>>>> API level.
>>> Sorry but no, see previous posts. Have a look at Seaside2.8a1-pmm.
>>> 583
>>> for what I would find acceptable.
>>
>> OK, can you explain how I should make Seaside work on both Pharo and
>> Squeak? I spent two days figuring out a minimal set of changes that
>> would not require doing some ugly hack testing for which underlying
>> platform you are dealing with and you say that is not acceptable? You
>> *want* ugly hacks? I don't understand...
>
> - Monkey patching either Seaside or Kom is not acceptable. We have  
> this
> issue partially because Kom is monkey patching Squeak.
> - Forking Seaside for Pharo is not acceptable.
> - Relying on a forked Kom is not acceptable, we need to have a
> consistent interface for Kom in both Squeak an Pharo.
>
> That kinda limits our options.
>
> Second the fix is not that ugly. It just sends #asString to  
> something it
> expects to be a String. This is not a that uncommon idiom. And we
> already have to do something way uglier for ensuring author initials.
>
> That's what happens if you break the API. You brake a lot of code and
> cause a lot of pain for a lot of people.
>
> Cheers
> Philippe
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> On Feb 25, 2009, at 5:59 PM, Michael Rueger wrote:
>
>> Lukas Renggli wrote:
>>>> what seasiders think?
>>>> I would be in favor to get a KOM pharo version
>>> Having two incompatible versions of Kom makes distribution even more
>>> painful as it is today. I would prefer to have compatible versions if
>>> this is possible.
>> As I said, we are at or at least close to the point where we have to
>> make the decision which version to support. If you want to have Pharo
>> stay compatible with Squeak, we can just as well abandon Pharo now.
>> It's as simple as that.
>
> No else we would not have done pharo.
> The point is more how can we help people migrating to pharo.
> Probably having a specific Kom version.