[squeak-dev] Removal of Web Browser Support in FileStream

patrick.rein at hpi.uni-potsdam.de patrick.rein at hpi.uni-potsdam.de
Wed May 8 12:57:04 UTC 2019


Sounds good. That means moving HTTPClient to the same package?

Bests
Patrick

>I agree, they can just be deprecated. It is unlikely that anyone will
>need them in the future.
>
>But I also like Chris' idea of putting the changes in a package, so here
>is a small suggestion: The deprecated methods (in the change set) are
>all in package 60Deprecated-System-Support. If the method category for
>these methods was changed from '*60Deprecated-System-Support' to
>'*60Deprecated-NSPlugin-System-Support' it would help to keep track
>of them in case anyone ever wanted to reload the methods.
>
>Dave
>
>
>On Tue, May 07, 2019 at 03:44:43PM -0500, Chris Muller wrote:
>> For a moment I wondered whether it would be worth trying to move these
>> methods (along with the others associated with In-Browser support)
>> into their own package which could be externally loaded back in to a
>> recent Squeak to enable running in Browser again.  But I couldn't
>> think of a single useful use-case why anyone would want to, plus
>> perhaps it's not supported by modern VM's anyway:
>> 
>>    StandardFileStream privateCheckForBrowserPrimitives      "false"
>> 
>> Deprecation seems to be the right track for these methods.
>> 
>> 
>> 
>> On Tue, May 7, 2019 at 7:18 AM Rein, Patrick <Patrick.Rein at hpi.de> wrote:
>> >
>> > Hi everyone,
>> >
>> > some weeks ago I asked regarding the support for running Squeak as a browser plugin and the consensus was to deprecate the code for it. While deprecating the corresponding methods, I also noticed some related protocols which build upon the web browser request protocol but are not used by anyone except for the also deprecated HTTPClient. My current strategy was to go ahead and deprecate these methods also. You can find the resulting methods in the changeset attached. Alternatively, we could try to convert these methods to a WebClient- or HTTPSocket-based implementation. However, without actual use cases in the trunk image this does not feel like it would be worth the effort.
>> >
>> > Any thoughts? :)
>> >
>> > Bests
>> > Patrick
>> 
>


More information about the Squeak-dev mailing list