+1

On Tue, Jul 6, 2021 at 3:13 PM Tobias Pape Das.Linux@gmx.de wrote:

YES

...

On 6. Jul 2021, at 15:06, Marcel Taeumel marcel.taeumel@hpi.de wrote:

Hi all!

I think it would be nice to have JSON as part of Squeak Trunk. This would make parsing the content of web requests easier. Recently, I got lucky to find the last-modified date in the HTTP header for the public TravisCI badge. But usually, one would have to query the official endpoint/API to then get XML or JSON content.

http://www.squeaksource.com/JSON

What do you think? The project is

• Self-contained
• Stable since 2016
• Not that big

o Adding the extension #jsonWriteOn: to the system

Latest maintainers seem to be: Hannes Hirzel (hjh, 2010) Levente Uzonyi (ul, 2010) Tony Garnock-Jones (tonyg, 2016) Fabio Niephaus (FabN, 2016)

Best, Marcel

Hi Christoph,

good points. I would like to unify all three efforts of JSON parsing: (1) http://www.squeaksource.com/JSON [http://www.squeaksource.com/JSON] (2) http://squeaksource.com/PostgresV3/JSON-ul.56.mcz [http://squeaksource.com/PostgresV3/JSON-ul.56.mcz] (3) WebUtils class >> #json{De,En}code:

I think that (1) is usually loaded in projects using JSON. I think that (2) has valuable fixes and extensions for (1).

I think that (3) is hardly ever used. In Trunk, only in the WebClientServerTests.

Thus, it makes sense to move (1) to Trunk, deprecate (3), and finally take a look at how to benefit from (2).

Hmm... I wonder whether my perspective on and usage of JSON is correct. Yes, it is strongly connected to Web content. Yet, it is also a quite compact form to generate into a local file. Squeak's #storeString seems more bloated sometimes. Looking at WebUtils, most of my past scenarios would have worked using those, too. I suppose. Especially that recent one with TravisCI. :-)

Best, Marcel Am 06.07.2021 15:32:33 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel, hi all,

I'm also a frequent user of JSON. I especially use it often for scripting tasks where it would be very helpful to have it in the Trunk by default.

However, I would also like to mention that we already have a small but working JSON implementation in WebUtils. See WebUtils class >> #json{De,En}code:. I'm not aware of all its limitations, but apparently, it does not have proper support for Unicode strings (\u...). Apart from that, it decodes to regular Dictionaries whereas JSON has JsonObjects with dynamic forwarding instead. Probably it would be a good idea to join these two concepts if we integrate JSON into the Trunk.

Also, consider Levente's fork of JSON, which we probably would like to merge as well: http://forum.world.st/I-d-like-to-contribute-to-the-JSON-project-tp5121353p5... [http://forum.world.st/I-d-like-to-contribute-to-the-JSON-project-tp5121353p5...]

---

As another whataboutistic comment, what is about STON? Currently, it resists as a kind of hidden [https://github.com/squeak-smalltalk/squeak-ston/issues/5%5D%C2%A0fork on GitHub, and for some reason, smalltalkCI holds a hard copy of it. Could we argue to add it to the Trunk as well? 😊

Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Fabio Niephaus lists@fniephaus.com Gesendet: Dienstag, 6. Juli 2021 15:17:12 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] JSON into Trunk? =)   +1

On Tue, Jul 6, 2021 at 3:13 PM Tobias Pape Das.Linux@gmx.de wrote:

YES

...

On 6. Jul 2021, at 15:06, Marcel Taeumel marcel.taeumel@hpi.de wrote:

Hi all!

I think it would be nice to have JSON as part of Squeak Trunk. This would make parsing the content of web requests easier. Recently, I got lucky to find the last-modified date in the HTTP header for the public TravisCI badge. But usually, one would have to query the official endpoint/API to then get XML or JSON content.

http://www.squeaksource.com/JSON [http://www.squeaksource.com/JSON]

What do you think? The project is

• Self-contained
• Stable since 2016
• Not that big

o Adding the extension #jsonWriteOn: to the system

Latest maintainers seem to be: Hannes Hirzel (hjh, 2010) Levente Uzonyi (ul, 2010) Tony Garnock-Jones (tonyg, 2016) Fabio Niephaus (FabN, 2016)

Best, Marcel

In terms of "dreams of the future", here is another observation I often made when using JSON (still "by the way" only):

I often found myself writing a tiny converter that converts snake_cased JSON keys into Smalltalkish camelCased keys and the other way around, just because it would be ugly to use underscore selectors in Squeak:

updates := self getUpdates: '/posts'.

updates do: [:update |

posts at: update post_id put: update post_text]. ":-("

I wonder whether this could be a relevant part of the JSON package as well? Just asking this here because it might hypothetically help us to gain a better understanding of the right shape and scope of this package ... :-)

Best,

Christoph

________________________________ Von: Thiede, Christoph Gesendet: Dienstag, 6. Juli 2021 17:29:41 An: squeak-dev Betreff: AW: [squeak-dev] JSON into Trunk? =)

Thus, it makes sense to move (1) to Trunk, deprecate (3), and finally take a look at how to benefit from (2).

+1 Maybe keep the public selectors on WebUtils and forward them to the "new" JSON protocol for compatibility reasons?

My comments on STON were not meant as an objection, just as a "related idea", so please keep going! :-) (Another related idea is to build a YAML converter analogously for JSON. If we did this, I wonder they would belong in the same package and if yes, whether this package would still be named JSON. But that's still all dreams of the future ... :D)

Best, Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 6. Juli 2021 16:23:55 An: squeak-dev Betreff: Re: [squeak-dev] JSON into Trunk? =)

Hi Christoph,

good points. I would like to unify all three efforts of JSON parsing: (1) http://www.squeaksource.com/JSON (2) http://squeaksource.com/PostgresV3/JSON-ul.56.mcz (3) WebUtils class >> #json{De,En}code:

I think that (1) is usually loaded in projects using JSON. I think that (2) has valuable fixes and extensions for (1). I think that (3) is hardly ever used. In Trunk, only in the WebClientServerTests.

Thus, it makes sense to move (1) to Trunk, deprecate (3), and finally take a look at how to benefit from (2).

Hmm... I wonder whether my perspective on and usage of JSON is correct. Yes, it is strongly connected to Web content. Yet, it is also a quite compact form to generate into a local file. Squeak's #storeString seems more bloated sometimes. Looking at WebUtils, most of my past scenarios would have worked using those, too. I suppose. Especially that recent one with TravisCI. :-)

Best, Marcel

Am 06.07.2021 15:32:33 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:

Hi Marcel, hi all,

I'm also a frequent user of JSON. I especially use it often for scripting tasks where it would be very helpful to have it in the Trunk by default.

However, I would also like to mention that we already have a small but working JSON implementation in WebUtils. See WebUtils class >> #json{De,En}code:. I'm not aware of all its limitations, but apparently, it does not have proper support for Unicode strings (\u...). Apart from that, it decodes to regular Dictionaries whereas JSON has JsonObjects with dynamic forwarding instead. Probably it would be a good idea to join these two concepts if we integrate JSON into the Trunk.

Also, consider Levente's fork of JSON, which we probably would like to merge as well: http://forum.world.st/I-d-like-to-contribute-to-the-JSON-project-tp5121353p5...

---

As another whataboutistic comment, what is about STON? Currently, it resists as a kind of hiddenhttps://github.com/squeak-smalltalk/squeak-ston/issues/5 fork on GitHub, and for some reason, smalltalkCI holds a hard copy of it. Could we argue to add it to the Trunk as well? 😊

Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Fabio Niephaus lists@fniephaus.com Gesendet: Dienstag, 6. Juli 2021 15:17:12 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] JSON into Trunk? =)

+1

On Tue, Jul 6, 2021 at 3:13 PM Tobias Pape Das.Linux@gmx.de wrote:

YES

...

On 6. Jul 2021, at 15:06, Marcel Taeumel marcel.taeumel@hpi.de wrote:

Hi all!

I think it would be nice to have JSON as part of Squeak Trunk. This would make parsing the content of web requests easier. Recently, I got lucky to find the last-modified date in the HTTP header for the public TravisCI badge. But usually, one would have to query the official endpoint/API to then get XML or JSON content.

http://www.squeaksource.com/JSON

What do you think? The project is

• Self-contained
• Stable since 2016
• Not that big

o Adding the extension #jsonWriteOn: to the system

Latest maintainers seem to be: Hannes Hirzel (hjh, 2010) Levente Uzonyi (ul, 2010) Tony Garnock-Jones (tonyg, 2016) Fabio Niephaus (FabN, 2016)

Best, Marcel

On 2021-07-06, at 7:23 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:

Hmm... I wonder whether my perspective on and usage of JSON is correct. Yes, it is strongly connected to Web content. Yet, it is also a quite compact form to generate into a local file. Squeak's #storeString seems more bloated sometimes. Looking at WebUtils, most of my past scenarios would have worked using those, too. I suppose. Especially that recent one with TravisCI. :-)

JSON is a good quick solution for simple storage stuff; I use it to record my weather station data etc. For more complex data we ('we' in this case being SageTea.ai) are using SIXX for some fairly complicated structure storage with good results. It seems to be decently fast and reliable, and usefully human-readable when doing emergency WTF! debugging in a text editor. It also compresses really well (about 30 to 1 for us) and the ZipArchive classes handle it very effectively. Masashi-san updated it last year to cleanly load in 5.3 after I found a couple of buglets.

The only drawback with it is that the home page (http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html) includes a link to the intriguing sounding SMIX (Smalltalk Interchange In XML) page, and here I must warn you to put on peril-sensitive sunglasses because the choice of page background colour may well represent a danger to your health.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Can easily be confused with facts.

Hi

On 7. Jul 2021, at 14:50, Levente Uzonyi leves@caesar.elte.hu wrote:

Hi Marcel,

On Tue, 6 Jul 2021, Marcel Taeumel wrote:

...

good points. I would like to unify all three efforts of JSON parsing: (1) http://www.squeaksource.com/JSON (2) http://squeaksource.com/PostgresV3/JSON-ul.56.mcz (3) WebUtils class >> #json{De,En}code: I think that (1) is usually loaded in projects using JSON. I think that (2) has valuable fixes and extensions for (1). I think that (3) is hardly ever used. In Trunk, only in the WebClientServerTests. Thus, it makes sense to move (1) to Trunk, deprecate (3), and finally take a look at how to benefit from (2).

(2) is already merged with the latest from (1).

Heres what I would do:

- Have Tony merge 2 back to 1. - Mark (1) as read-only for old Squeak'en (so someone using 4.5 can have JSON) - Copy all of (1) to Trunk. - Adapt webclient.

Best regards -Tobias

The "Heres what I would do" plan from Tobias (below) sounds to me like the right way forward. I don't know if anyone is working on it though.

Dave

On Mon, Aug 30, 2021 at 12:29:45PM +0200, christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi all,

looks like this discussion has stagnated, but I would still love to get the current jungle of JSON sources solved. Just today I have been encountering another version conflict from loading different JSON forks into my image ... We could really fix this problem by shipping an "official" version of JSON with the Trunk.

Marcel's mime type argument is a very good point IMHO.

...

...

On 7. Jul 2021, at 14:50, Levente Uzonyi <leves at caesar.elte.hu> wrote:

Hi Marcel,

On Tue, 6 Jul 2021, Marcel Taeumel wrote:

...

good points. I would like to unify all three efforts of JSON parsing: (1) http://www.squeaksource.com/JSON (2) http://squeaksource.com/PostgresV3/JSON-ul.56.mcz (3) WebUtils class >> #json{De,En}code: I think that (1) is usually loaded in projects using JSON. I think that (2) has valuable fixes and extensions for (1). I think that (3) is hardly ever used. In Trunk, only in the WebClientServerTests. Thus, it makes sense to move (1) to Trunk, deprecate (3), and finally take a look at how to benefit from (2).

(2) is already merged with the latest from (1).

Heres what I would do:

• Have Tony merge 2 back to 1.
• Mark (1) as read-only for old Squeak'en (so someone using 4.5 can have JSON)
• Copy all of (1) to Trunk.
• Adapt webclient.

I don't think it's necessary to wait for Tony again, as we know that Levente's fork includes all recent changes to the JSON package. I would opt for immediately copying Levente's version of JSON into a new package; after that, we can deprecate the existing packages and adapt the WebClient.

What is hindering us from doing this? Can I help? :D

Best, Christoph

---

Sent from Squeak Inbox Talk

On 2021-07-07T15:00:16+02:00, das.linux@gmx.de wrote:

...

Hi

...

On 7. Jul 2021, at 14:50, Levente Uzonyi <leves at caesar.elte.hu> wrote:

Hi Marcel,

On Tue, 6 Jul 2021, Marcel Taeumel wrote:

...

good points. I would like to unify all three efforts of JSON parsing: (1) http://www.squeaksource.com/JSON (2) http://squeaksource.com/PostgresV3/JSON-ul.56.mcz (3) WebUtils class >> #json{De,En}code: I think that (1) is usually loaded in projects using JSON. I think that (2) has valuable fixes and extensions for (1). I think that (3) is hardly ever used. In Trunk, only in the WebClientServerTests. Thus, it makes sense to move (1) to Trunk, deprecate (3), and finally take a look at how to benefit from (2).

(2) is already merged with the latest from (1).

Heres what I would do:

• Have Tony merge 2 back to 1.
• Mark (1) as read-only for old Squeak'en (so someone using 4.5 can have JSON)
• Copy all of (1) to Trunk.
• Adapt webclient.

Best regards ????-Tobias

If Tony should be busy or no longer maintaining his fork, you could also ask me to do that boring merge task. Then I could send you an MCZ ready to integrate it into the Trunk. :-)

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2021-08-30T21:34:27+02:00, das.linux@gmx.de wrote:

Hi Hi Tony

...

On 30. Aug 2021, at 21:20, David T. Lewis <lewis at mail.msen.com> wrote:

The "Heres what I would do" plan from Tobias (below) sounds to me like the right way forward. I don't know if anyone is working on it though.

Tony, would it be possible for you to merge      http://squeaksource.com/PostgresV3/JSON-ul.56.mcz into http://www.squeaksource.com/JSON ?

Best regards     -Tobias

...

Dave

On Mon, Aug 30, 2021 at 12:29:45PM +0200, christoph.thiede at student.hpi.uni-potsdam.de wrote:

...

Hi all,

looks like this discussion has stagnated, but I would still love to get the current jungle of JSON sources solved. Just today I have been encountering another version conflict from loading different JSON forks into my image ... We could really fix this problem by shipping an "official" version of JSON with the Trunk.

Marcel's mime type argument is a very good point IMHO.

...

...

On 7. Jul 2021, at 14:50, Levente Uzonyi <leves at caesar.elte.hu> wrote:

Hi Marcel,

On Tue, 6 Jul 2021, Marcel Taeumel wrote:

...

good points. I would like to unify all three efforts of JSON parsing: (1) http://www.squeaksource.com/JSON (2) http://squeaksource.com/PostgresV3/JSON-ul.56.mcz (3) WebUtils class >> #json{De,En}code: I think that (1) is usually loaded in projects using JSON. I think that (2) has valuable fixes and extensions for (1). I think that (3) is hardly ever used. In Trunk, only in the WebClientServerTests. Thus, it makes sense to move (1) to Trunk, deprecate (3), and finally take a look at how to benefit from (2).

(2) is already merged with the latest from (1).

Heres what I would do:

• Have Tony merge 2 back to 1.
• Mark (1) as read-only for old Squeak'en (so someone using 4.5 can have JSON)
• Copy all of (1) to Trunk.
• Adapt webclient.

I don't think it's necessary to wait for Tony again, as we know that Levente's fork includes all recent changes to the JSON package. I would opt for immediately copying Levente's version of JSON into a new package; after that, we can deprecate the existing packages and adapt the WebClient.

What is hindering us from doing this? Can I help? :D

Best, Christoph

---

Sent from Squeak Inbox Talk

On 2021-07-07T15:00:16+02:00, das.linux at gmx.de wrote:

...

Hi

...

On 7. Jul 2021, at 14:50, Levente Uzonyi <leves at caesar.elte.hu> wrote:

Hi Marcel,

On Tue, 6 Jul 2021, Marcel Taeumel wrote:

...

good points. I would like to unify all three efforts of JSON parsing: (1) http://www.squeaksource.com/JSON (2) http://squeaksource.com/PostgresV3/JSON-ul.56.mcz (3) WebUtils class >> #json{De,En}code: I think that (1) is usually loaded in projects using JSON. I think that (2) has valuable fixes and extensions for (1). I think that (3) is hardly ever used. In Trunk, only in the WebClientServerTests. Thus, it makes sense to move (1) to Trunk, deprecate (3), and finally take a look at how to benefit from (2).

(2) is already merged with the latest from (1).

Heres what I would do:

• Have Tony merge 2 back to 1.
• Mark (1) as read-only for old Squeak'en (so someone using 4.5 can have JSON)
• Copy all of (1) to Trunk.
• Adapt webclient.

Best regards ????-Tobias

Sounds reasonable from the "what do people nowadays expect" perspective. +1

Fabio Niephaus lists@fniephaus.com schrieb am Di., 6. Juli 2021, 15:17:

+1

On Tue, Jul 6, 2021 at 3:13 PM Tobias Pape Das.Linux@gmx.de wrote:

...

YES

...

On 6. Jul 2021, at 15:06, Marcel Taeumel marcel.taeumel@hpi.de

wrote:

...

...

Hi all!

I think it would be nice to have JSON as part of Squeak Trunk. This

would make parsing the content of web requests easier. Recently, I got lucky to find the last-modified date in the HTTP header for the public TravisCI badge. But usually, one would have to query the official endpoint/API to then get XML or JSON content.

...

...

http://www.squeaksource.com/JSON

What do you think? The project is

• Self-contained
• Stable since 2016
• Not that big

o Adding the extension #jsonWriteOn: to the system

Latest maintainers seem to be: Hannes Hirzel (hjh, 2010) Levente Uzonyi (ul, 2010) Tony Garnock-Jones (tonyg, 2016) Fabio Niephaus (FabN, 2016)

Best, Marcel

On 2021-07-06, at 4:33 PM, David T. Lewis lewis@mail.msen.com wrote:

If it is already stable, high quality, and useful, then why does it need to be in trunk? This seems like exactly the kind of package that we want to be easily found and installed through something like SqueakMap.

My argument for including it is basically that we have a sorta-kinda JSON package in the the WebClient-Core package that would benefit from being upgraded/replaced by work from the above mentioned versions. These days web capability is so pervasive that we probably have to Just DoIt.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One bit short of a word.