October 2014 - Pharo-dev - lists.pharo.org

Pharo days: date proposal

by stepharo

Hi pharoers and others happy hackers we would like to organize PharoDays a two days gathering mix between a conference and a huge sprint. We thought that the 29 and 30 of January 2015 is a good date. Now before launching the organization process we would like to know if there is not a huge conflict that we did not see. Stef on the behalf of the Pharo board

Oct. 2, 2014

Re: [Pharo-dev] GT Playground/Inspect window menu

by Tudor Girba

Hi, The menu is consciously not there. The reason for that goes as follows: by default in Morphic every window gets the generic menu that nobody really uses, but some windows also put in there dedicated menu entries like the "show previous contents" from the old Workspace. The problem is that you have no chance of knowing which window actually hold useful entries from outside. That is why in Glamour you have to have a window specific action in order to get the menu at all. About save/load, this feature will come in some form. About the tabs: every presentation that has a title is shown like a tab. It is actually true that we would like to have multiple tabs, but we did not get to a proper solution yet :). Cheers, Doru On Thu, Oct 2, 2014 at 4:00 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > 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 > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 2, 2014

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

by CÃ©drick BÃ©ler

Hi all, This is actually doable to use a POST request instead of a GET. ZnClient new url: 'https://smsapi.free-mobile.fr/sendmsg'; queryAt: #user put: '12345'; queryAt: #pass put: 'sqsdqsfzedfqsd'; queryAt: #msg put: 'Hi again From Pharo Ã©@Ã¨!Â§'; post. Tested OK. BTW, I'm using a GSM modem with Gnokii deamon to use it as a SMS server on a NAS Synology. The problem with the smsapi proposed before is that it can only send to your mobile and it has a dependance on the internet connection. This is a more universal option, but then it's far more tricky to interface. I right now use a script in python to expose a "webservice" url so send message... But I need a better way to do it (my aim is to be able to have a communication channel other than email so that I can send group message, query and treat responses (YES NO...)). Cheers, CÃ©drick 2014-10-02 15:34 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > 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> 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. > > > -- CÃ©drick

Oct. 2, 2014

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