Hi Yuriy, On 13 Jan 2014, at 17:42, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 13 Jan 2014, at 16:36, Marcus Denker <marcus.denker@inria.fr> wrote:
Fuel is included, but that implements a binary, not textual encoding. IMHO it would make sense to include either or both STON and NeoJSON. On the other hand, the same can be said about many external frameworks. You can very easily load both STON or NeoJSON manually.
Thanks, Sven.
I just wonder what are the plans for future, because knowing that some functionality will be available by default helps me to introduce new interesting workflows.
Why?
Because itâs nice if you can do something with just âvanillaâ Pharo. Yes, STON is easy to load, but if you want to automate something you have to preload it, and if you are not automating you have to do the thing over and over again. I want to come up with something cool and say: âLook, you can do this and this and get awesome resultâ. The less âthisâs are the better it is (IMHO). So if STON will be preloaded and JSON - not, I will definitely go with STON. If not - probably JSON, as it has more support across different tools. Etc.
This isnât really special. Just bugs in my head :)
I do understand what you are thinking of, but it is really easy and elegant to bootstrap: Gofer it smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo30'; configurationOf: 'Ston'; loadStable. Sven BTW, STON is a supercase of JSON, its parser can do general/simple JSON parsing to Dictionaries and Arrays, and its writer can produce valid JSON. Here is an example: ZnClient new systemPolicy; url: 'http://easy.t3-platform.net/rest/geo-ip'; queryAt: 'address' put: '81.83.7.35'; accept: ZnMimeType applicationJson; contentReader: [ :entity | #STON asClass fromString: entity contents ]; get. -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org