Any pre-installed (text) deserializer?
Hi everyone. I want to hold some data (configuration) online and load it into my image on demand with Zinc. Is there any deserialiser like JSON or STON pre-installed in the image? Are there plans to include anything in the future?
Yuriy, On 13 Jan 2014, at 16:06, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
I want to hold some data (configuration) online and load it into my image on demand with Zinc. Is there any deserialiser like JSON or STON pre-installed in the image? Are there plans to include anything in the future?
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. Sven
On 13 Jan 2014, at 16:26, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yuriy,
On 13 Jan 2014, at 16:06, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi everyone.
I want to hold some data (configuration) online and load it into my image on demand with Zinc. Is there any deserialiser like JSON or STON pre-installed in the image? Are there plans to include anything in the future?
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. Uko
Sven
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?
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 :) Uko
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
Sven Van Caekenberghe-2 wrote
I do understand what you are thinking of, but it is really easy and elegant to bootstrap:
Or create your own Metacello configuration for your project and the user never has to know anything about the dependencies ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Any-pre-installed-text-deserializer-tp4736401p4736523.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (4)
-
Marcus Denker -
Sean P. DeNigris -
Sven Van Caekenberghe -
Yuriy Tymchuk