Removal of Web Browser Support in FileStream

> 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 <[hidden email]> 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
>

>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 <[hidden email]> 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
>>
>

> 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 <[hidden email]> 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
> >>
> >
>

>I am not sure, but I think HTTPClient was a more general-purpose class,
>not just for NS browser support? So having it in 60Deprecated-System-Support
>still seems right.
>
>But I am not very familiar with this part of the system so please use
>your own choice for this and it will be good :-)
>
>Dave
>
>
>On Wed, May 08, 2019 at 02:57:04PM +0200, [hidden email] wrote:
>> 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 <[hidden email]> 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
>> >>
>> >
>>
>