- Pharo-dev - lists.pharo.org

GT Playground/Inspect window menu

by Peter UhnÃ¡k

Hi, I've noticed that the window menu (in top right corner) is missing when I create the window for the first time. But if I drag it inside window group and then take it out it appears, in inspector's case it replaces the update button with window menu button. The window group content was more rich in Workspace; the open / save functionality in particular. (But maybe I was the last person using it and I should use ScriptManager instead). The last thing... the top part looks like a Tab, so is it possible to add second Playground next to it instead of using groups? And now to spend the rest of the day playing with it all, it looks amazing ^^. Peter

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by Norbert Hartl

> Am 02.10.2014 um 15:25 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 02 Oct 2014, at 15:19, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > >>> >>> Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: >>> >>> 2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>>> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>>> >>>>> ps: It is funny they use GET to send a message. :) >>>> >>>> I was going to comment on that as well. For an action, the common REST practice dictates doing a POST. GET is to request the contents of something. >>>> >>>> Putting authentication in headers is also better, because it is more orthogonal. >>>> >>>> In full REST speak, you POST to a /sender resource which creates a new resource like /sms/123123 which you can then query for state (because it can take a while to determine success of failure) - this could also contain delivery timestamp, number of retries, proof of delivery and full contents for future/historic reference. >>> >>> Exactly! >>> >>> GET (and HEAD) should be idempotent, so two identical GET requests shouldn't >>> cause any resource/server state modification. [1] >>> >> That's not true. It should not modify the resource identified by the URI. But is still possible to have side effects. Otherwise a GET request that produces a line in a logfile would be impossible, right? > > Nothing you said is wrong (including your other mail), but for us, a log service where a GET would add data would not fly, that would definitively have to be a POST. > Sure. I don't think we need to argue here because we would mostly agree on all those things. I just wanted to clarify my point by providing a simple example. The log I meant is that of a frontend web server like apache, that adds a line to a log file even on GET request. Just food for thought about a statement "â¦shouldn't cause any resource/server state modificationâ¦" Norbert > But yes, it is more about design, not about what is forbidden, it is about conventions. The whole HTTP design is a bit unclear. > >> And btw. all verbs are idempotent except PATCH and POST. >> >> Norbert >> >>> Esteban A. Maringolo >>> >>> [1] We all now Seaside also breaks this rule by design (hence its >>> "heretic" tagline), and there isn't any foreseeable way of changing >>> this to comply with HTTP recommended usage.

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by Esteban A. Maringolo

2014-10-02 10:19 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > >> Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: >> >> 2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>> >>>> ps: It is funny they use GET to send a message. :) >>> >>> I was going to comment on that as well. For an action, the common REST practice dictates doing a POST. GET is to request the contents of something. >>> >>> Putting authentication in headers is also better, because it is more orthogonal. >>> >>> In full REST speak, you POST to a /sender resource which creates a new resource like /sms/123123 which you can then query for state (because it can take a while to determine success of failure) - this could also contain delivery timestamp, number of retries, proof of delivery and full contents for future/historic reference. >> >> Exactly! >> >> GET (and HEAD) should be idempotent, so two identical GET requests shouldn't >> cause any resource/server state modification. [1] >> > That's not true. It should not modify the resource identified by the URI. But is still possible to have side effects. > Otherwise a GET request that produces a line in a logfile would be impossible, right? You're right, but generally speaking logging is orthogonal to the resource itself. > And btw. all verbs are idempotent except PATCH and POST. Strictly speaking also true, but two *identical* DELETE requests to the same URI will first return a 200 and then a 404. Also two *identical* PUT request with a version identifier (sort of MVCC) will succeed the first time and fail the second. This is more a matter of convention. I'm not a REST purist myself. But certain HTTP client libraries, particularly for mobile, can request (or even submit) more than once. Regards, Esteban A. Maringolo

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by Sven Van Caekenberghe

On 02 Oct 2014, at 15:19, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: >> >> 2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>> >>>> ps: It is funny they use GET to send a message. :) >>> >>> I was going to comment on that as well. For an action, the common REST practice dictates doing a POST. GET is to request the contents of something. >>> >>> Putting authentication in headers is also better, because it is more orthogonal. >>> >>> In full REST speak, you POST to a /sender resource which creates a new resource like /sms/123123 which you can then query for state (because it can take a while to determine success of failure) - this could also contain delivery timestamp, number of retries, proof of delivery and full contents for future/historic reference. >> >> Exactly! >> >> GET (and HEAD) should be idempotent, so two identical GET requests shouldn't >> cause any resource/server state modification. [1] >> > That's not true. It should not modify the resource identified by the URI. But is still possible to have side effects. Otherwise a GET request that produces a line in a logfile would be impossible, right? Nothing you said is wrong (including your other mail), but for us, a log service where a GET would add data would not fly, that would definitively have to be a POST. But yes, it is more about design, not about what is forbidden, it is about conventions. The whole HTTP design is a bit unclear. > And btw. all verbs are idempotent except PATCH and POST. > > Norbert > >> Esteban A. Maringolo >> >> [1] We all now Seaside also breaks this rule by design (hence its >> "heretic" tagline), and there isn't any foreseeable way of changing >> this to comply with HTTP recommended usage.

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by Norbert Hartl

> Am 02.10.2014 um 15:07 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > > 2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> ps: It is funny they use GET to send a message. :) >> >> I was going to comment on that as well. For an action, the common REST practice dictates doing a POST. GET is to request the contents of something. >> >> Putting authentication in headers is also better, because it is more orthogonal. >> >> In full REST speak, you POST to a /sender resource which creates a new resource like /sms/123123 which you can then query for state (because it can take a while to determine success of failure) - this could also contain delivery timestamp, number of retries, proof of delivery and full contents for future/historic reference. > > Exactly! > > GET (and HEAD) should be idempotent, so two identical GET requests shouldn't > cause any resource/server state modification. [1] > That's not true. It should not modify the resource identified by the URI. But is still possible to have side effects. Otherwise a GET request that produces a line in a logfile would be impossible, right? And btw. all verbs are idempotent except PATCH and POST. Norbert > Esteban A. Maringolo > > [1] We all now Seaside also breaks this rule by design (hence its > "heretic" tagline), and there isn't any foreseeable way of changing > this to comply with HTTP recommended usage. >

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by Norbert Hartl

> Am 02.10.2014 um 14:56 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> 2014-10-02 7:57 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>> Too bad I live in a retared telecom-wise and mobile-competition wise >>> country. >> >> You're not alone. >> >> Esteban A. Maringolo >> >> ps: It is funny they use GET to send a message. :) > > I was going to comment on that as well. For an action, the common REST practice dictates doing a POST. GET is to request the contents of something. > > Putting authentication in headers is also better, because it is more orthogonal. > > In full REST speak, you POST to a /sender resource which creates a new resource like /sms/123123 which you can then query for state (because it can take a while to determine success of failure) - this could also contain delivery timestamp, number of retries, proof of delivery and full contents for future/historic reference. In REST speak you have to see that there are two types of resources. A resource that represents the resource identified by the URI (itself) and a processing resource that takes the content and produces something else. For HEAD, PUT and DELETE this is the former type. POST is always the latter. And here the "creation of a new resource below the collection" is just a convention not a necessity. The case for GET is that it serves both use cases. They acquire a resource from the URI regardless if it is the entity in the URI or the processing entity. The problem with GET API method seems to be that they are produced by lazy/inexperienced developers. The benefit of GET URLs is that you can put them in a mail. The whole REST approach leaves us alone with a use case like a confirmation mail. Same goes for GET requests containing a body. my 2 cents, Norbert

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by Esteban A. Maringolo

2014-10-02 9:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> ps: It is funny they use GET to send a message. :) > > I was going to comment on that as well. For an action, the common REST practice dictates doing a POST. GET is to request the contents of something. > > Putting authentication in headers is also better, because it is more orthogonal. > > In full REST speak, you POST to a /sender resource which creates a new resource like /sms/123123 which you can then query for state (because it can take a while to determine success of failure) - this could also contain delivery timestamp, number of retries, proof of delivery and full contents for future/historic reference. Exactly! GET (and HEAD) should be idempotent, so two identical GET requests shouldn't cause any resource/server state modification. [1] Esteban A. Maringolo [1] We all now Seaside also breaks this rule by design (hence its "heretic" tagline), and there isn't any foreseeable way of changing this to comply with HTTP recommended usage.

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by Sven Van Caekenberghe

On 02 Oct 2014, at 14:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-10-02 7:57 GMT-03:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> Too bad I live in a retared telecom-wise and mobile-competition wise >> country. > > You're not alone. > > Esteban A. Maringolo > > ps: It is funny they use GET to send a message. :) I was going to comment on that as well. For an action, the common REST practice dictates doing a POST. GET is to request the contents of something. Putting authentication in headers is also better, because it is more orthogonal. In full REST speak, you POST to a /sender resource which creates a new resource like /sms/123123 which you can then query for state (because it can take a while to determine success of failure) - this could also contain delivery timestamp, number of retries, proof of delivery and full contents for future/historic reference. Sven

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by Noury Bouraqadi

thanks Sven for the example, and more importantly for Zinc :-) On 02 Oct 2014, at 14:21, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 02 Oct 2014, at 12:16, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > >> Hi, >> >> The Free french telecom company introduces a new feature that allow sending SMS to your own mobile phone using a HTTP query >> All you need is to activate the option at no cost, and use Pharo. Have fun :-) >> >> ZnEasy get: 'https://smsapi.free-mobile.fr/sendmsg?user=YourLogin&pass=YourPassword&msg=…' >> >> Noury >> > > That is cool, indeed. > > I would write it as > > ZnClient new > url: 'https://smsapi.free-mobile.fr/sendmsg'; > queryAt: #user put: 'YourLogin'; > queryAt: #pass put: 'YourPass'; > queryAt: #msg put: 'Hi From Pharo'; > get. > > The Percent Encoding and query building is then done for your. > > Sven

Oct. 2, 2014

Re: [Pharo-dev] Sending SMS through Pharo/HTTP

by phil＠highoctane.be

SMS is 160, which fits a query string.â

Oct. 2, 2014