November 2021 - Pharo-users

Re: Strategies for (re)using HTTP client

by Esteban Maringolo

Thanks Sven! I don't know whether I'm going to use it, but it's good that the feature is there and I have the option of sharing such session among clients. Regards, Esteban A. Maringolo On Wed, Nov 3, 2021 at 1:06 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Maybe this helps: > > > https://github.com/svenvc/zinc/commit/d9fe41707b16748b9340540127ec5d7780085… > > > On 1 Nov 2021, at 21:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > >> On 1 Nov 2021, at 20:03, Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > >> > >> If I need to use cookies, would it make sense to keep a > ZnUserAgentSession and assign it to each new client? > > > > I don't know or remember, my first reaction would be to say that it was > not designed for that purpose, but maybe it could be used for that. > > > >> I'm asking this in case I have to share cookies between requests. But > the session variable seems to be private in ZnClient given that it doesn't > provide any setter. > > > > There is the cookie jar object inside the session, maybe you can try to > share that ? > > > > Or you could copy the necessary cookies over ? That certainly seems like > the safest thing. > > > >> Regards, > >> > >> Esteban A. Maringolo > >> > >> > >> On Mon, Nov 1, 2021 at 1:39 PM Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > >> Thank you Sven. > >> > >> I'll go with instantiating a new client for each request, the less > state shared, the better :-) > >> > >> Regards! > >> > >> Esteban A. Maringolo > >> > >> > >> On Fri, Oct 29, 2021 at 12:15 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi, > >> > >>> On 29 Oct 2021, at 15:42, Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > >>> > >>> Hi, > >>> > >>> I happened to me more than once that I have to create some REST > service "client" in which I usually wrap an HTTP client inside (ZnClient in > this case), and all the calls to the service, end up using the HTTP client, > inside some mutex to serialize the execution. > >> > >> Yes, that is a good design. However, whether your REST client object > wrapping a ZnClient is used by multiple concurrent threads is another > decision. I would personally not do that. See further. > >> > >>> But I don't like that, in particular when some endpoints are better > with streaming responses (large downloads) and I have to fiddle with the > client and set it back to the settings before executing the request. > >> > >> You only can and should reuse connections to the same endpoint/service > only, doing similar types of request/responses (let's say simple ones). > >> > >> A definitive danger point is authentication and authorization: > different calls by different users might need different REST call settings, > each time. Also, caching can be a problem, if user A can see / sees the > cache of user B. > >> > >>> So, long story short... is it always safer to instantiate a new > ZnClient on a per request basis since no state is shared, but I guess it is > also less effective if I'm performing several requests to the same server. > >> > >> A new instance is definitely safer because it is cleaner. Reusing a > connection is more efficient when doing multiple calls in (quick) > succession. The penalty is usually pretty low, you can postpone optimising > until there is an actual problem. > >> > >> Error handling and recovery are also harder in the reuse case (what > state is the connection in ?). > >> > >> ZnClient does a form of automatic reconnection/retry though. > >> > >>> What are the recommended approaches here? > >>> > >>> > >>> Esteban A. Maringolo > >> > >> HTH, > >> > >> Sven > > >

Nov. 3, 2021

Re: Strategies for (re)using HTTP client

by Sven Van Caekenberghe

Maybe this helps: https://github.com/svenvc/zinc/commit/d9fe41707b16748b9340540127ec5d7780085… > On 1 Nov 2021, at 21:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 1 Nov 2021, at 20:03, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> If I need to use cookies, would it make sense to keep a ZnUserAgentSession and assign it to each new client? > > I don't know or remember, my first reaction would be to say that it was not designed for that purpose, but maybe it could be used for that. > >> I'm asking this in case I have to share cookies between requests. But the session variable seems to be private in ZnClient given that it doesn't provide any setter. > > There is the cookie jar object inside the session, maybe you can try to share that ? > > Or you could copy the necessary cookies over ? That certainly seems like the safest thing. > >> Regards, >> >> Esteban A. Maringolo >> >> >> On Mon, Nov 1, 2021 at 1:39 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> Thank you Sven. >> >> I'll go with instantiating a new client for each request, the less state shared, the better :-) >> >> Regards! >> >> Esteban A. Maringolo >> >> >> On Fri, Oct 29, 2021 at 12:15 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Hi, >> >>> On 29 Oct 2021, at 15:42, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I happened to me more than once that I have to create some REST service "client" in which I usually wrap an HTTP client inside (ZnClient in this case), and all the calls to the service, end up using the HTTP client, inside some mutex to serialize the execution. >> >> Yes, that is a good design. However, whether your REST client object wrapping a ZnClient is used by multiple concurrent threads is another decision. I would personally not do that. See further. >> >>> But I don't like that, in particular when some endpoints are better with streaming responses (large downloads) and I have to fiddle with the client and set it back to the settings before executing the request. >> >> You only can and should reuse connections to the same endpoint/service only, doing similar types of request/responses (let's say simple ones). >> >> A definitive danger point is authentication and authorization: different calls by different users might need different REST call settings, each time. Also, caching can be a problem, if user A can see / sees the cache of user B. >> >>> So, long story short... is it always safer to instantiate a new ZnClient on a per request basis since no state is shared, but I guess it is also less effective if I'm performing several requests to the same server. >> >> A new instance is definitely safer because it is cleaner. Reusing a connection is more efficient when doing multiple calls in (quick) succession. The penalty is usually pretty low, you can postpone optimising until there is an actual problem. >> >> Error handling and recovery are also harder in the reuse case (what state is the connection in ?). >> >> ZnClient does a form of automatic reconnection/retry though. >> >>> What are the recommended approaches here? >>> >>> >>> Esteban A. Maringolo >> >> HTH, >> >> Sven >

Nov. 3, 2021

Re: Can traits be removed programatically?

by Marcus Denker

You can just create > On 27 Oct 2021, at 11:07, Jupiter Jones <jupiter.jones(a)mail.com> wrote: > > Does anyone know how to remove a trait programatically? > you could use the class installer / class builder, e.g. imagine you have: Object subclass: #MyVisitor uses: TRBProgramNodeVisitor instanceVariableNames: '' classVariableNames: '' package: âPackageTestâ you can now remove the Trait with: ShiftClassInstaller make: [ :aClassBuilder | aClassBuilder fillFor: MyVisitor. aClassBuilder traitComposition: { } ] Marcus

Nov. 2, 2021

Re: Strategies for (re)using HTTP client

by Sven Van Caekenberghe

> On 1 Nov 2021, at 20:03, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > If I need to use cookies, would it make sense to keep a ZnUserAgentSession and assign it to each new client? I don't know or remember, my first reaction would be to say that it was not designed for that purpose, but maybe it could be used for that. > I'm asking this in case I have to share cookies between requests. But the session variable seems to be private in ZnClient given that it doesn't provide any setter. There is the cookie jar object inside the session, maybe you can try to share that ? Or you could copy the necessary cookies over ? That certainly seems like the safest thing. > Regards, > > Esteban A. Maringolo > > > On Mon, Nov 1, 2021 at 1:39 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > Thank you Sven. > > I'll go with instantiating a new client for each request, the less state shared, the better :-) > > Regards! > > Esteban A. Maringolo > > > On Fri, Oct 29, 2021 at 12:15 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > > On 29 Oct 2021, at 15:42, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > Hi, > > > > I happened to me more than once that I have to create some REST service "client" in which I usually wrap an HTTP client inside (ZnClient in this case), and all the calls to the service, end up using the HTTP client, inside some mutex to serialize the execution. > > Yes, that is a good design. However, whether your REST client object wrapping a ZnClient is used by multiple concurrent threads is another decision. I would personally not do that. See further. > > > But I don't like that, in particular when some endpoints are better with streaming responses (large downloads) and I have to fiddle with the client and set it back to the settings before executing the request. > > You only can and should reuse connections to the same endpoint/service only, doing similar types of request/responses (let's say simple ones). > > A definitive danger point is authentication and authorization: different calls by different users might need different REST call settings, each time. Also, caching can be a problem, if user A can see / sees the cache of user B. > > > So, long story short... is it always safer to instantiate a new ZnClient on a per request basis since no state is shared, but I guess it is also less effective if I'm performing several requests to the same server. > > A new instance is definitely safer because it is cleaner. Reusing a connection is more efficient when doing multiple calls in (quick) succession. The penalty is usually pretty low, you can postpone optimising until there is an actual problem. > > Error handling and recovery are also harder in the reuse case (what state is the connection in ?). > > ZnClient does a form of automatic reconnection/retry though. > > > What are the recommended approaches here? > > > > > > Esteban A. Maringolo > > HTH, > > Sven

Nov. 1, 2021

Re: Strategies for (re)using HTTP client

by Esteban Maringolo

If I need to use cookies, would it make sense to keep a ZnUserAgentSession and assign it to each new client? I'm asking this in case I have to share cookies between requests. But the session variable seems to be private in ZnClient given that it doesn't provide any setter. Regards, Esteban A. Maringolo On Mon, Nov 1, 2021 at 1:39 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > Thank you Sven. > > I'll go with instantiating a new client for each request, the less state > shared, the better :-) > > Regards! > > Esteban A. Maringolo > > > On Fri, Oct 29, 2021 at 12:15 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi, >> >> > On 29 Oct 2021, at 15:42, Esteban Maringolo <emaringolo(a)gmail.com> >> wrote: >> > >> > Hi, >> > >> > I happened to me more than once that I have to create some REST service >> "client" in which I usually wrap an HTTP client inside (ZnClient in this >> case), and all the calls to the service, end up using the HTTP client, >> inside some mutex to serialize the execution. >> >> Yes, that is a good design. However, whether your REST client object >> wrapping a ZnClient is used by multiple concurrent threads is another >> decision. I would personally not do that. See further. >> >> > But I don't like that, in particular when some endpoints are better >> with streaming responses (large downloads) and I have to fiddle with the >> client and set it back to the settings before executing the request. >> >> You only can and should reuse connections to the same endpoint/service >> only, doing similar types of request/responses (let's say simple ones). >> >> A definitive danger point is authentication and authorization: different >> calls by different users might need different REST call settings, each >> time. Also, caching can be a problem, if user A can see / sees the cache of >> user B. >> >> > So, long story short... is it always safer to instantiate a new >> ZnClient on a per request basis since no state is shared, but I guess it is >> also less effective if I'm performing several requests to the same server. >> >> A new instance is definitely safer because it is cleaner. Reusing a >> connection is more efficient when doing multiple calls in (quick) >> succession. The penalty is usually pretty low, you can postpone optimising >> until there is an actual problem. >> >> Error handling and recovery are also harder in the reuse case (what state >> is the connection in ?). >> >> ZnClient does a form of automatic reconnection/retry though. >> >> > What are the recommended approaches here? >> > >> > >> > Esteban A. Maringolo >> >> HTH, >> >> Sven >> >

Nov. 1, 2021

Re: Strategies for (re)using HTTP client

by Esteban Maringolo

Thank you Sven. I'll go with instantiating a new client for each request, the less state shared, the better :-) Regards! Esteban A. Maringolo On Fri, Oct 29, 2021 at 12:15 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > > On 29 Oct 2021, at 15:42, Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > > > > Hi, > > > > I happened to me more than once that I have to create some REST service > "client" in which I usually wrap an HTTP client inside (ZnClient in this > case), and all the calls to the service, end up using the HTTP client, > inside some mutex to serialize the execution. > > Yes, that is a good design. However, whether your REST client object > wrapping a ZnClient is used by multiple concurrent threads is another > decision. I would personally not do that. See further. > > > But I don't like that, in particular when some endpoints are better with > streaming responses (large downloads) and I have to fiddle with the client > and set it back to the settings before executing the request. > > You only can and should reuse connections to the same endpoint/service > only, doing similar types of request/responses (let's say simple ones). > > A definitive danger point is authentication and authorization: different > calls by different users might need different REST call settings, each > time. Also, caching can be a problem, if user A can see / sees the cache of > user B. > > > So, long story short... is it always safer to instantiate a new ZnClient > on a per request basis since no state is shared, but I guess it is also > less effective if I'm performing several requests to the same server. > > A new instance is definitely safer because it is cleaner. Reusing a > connection is more efficient when doing multiple calls in (quick) > succession. The penalty is usually pretty low, you can postpone optimising > until there is an actual problem. > > Error handling and recovery are also harder in the reuse case (what state > is the connection in ?). > > ZnClient does a form of automatic reconnection/retry though. > > > What are the recommended approaches here? > > > > > > Esteban A. Maringolo > > HTH, > > Sven >

Nov. 1, 2021