Is there an official JSON parser/writer?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Is there an official JSON parser/writer?

Esteban A. Maringolo
Hi,

tl;dr: Question: Which JSON library is the "recommended" one?


Long:
I'm modifying the PostgresV2 package to support JSON datatype but
instead of using the JSON package from PharoExtras I'm trying to use
NeoJSON.

The problem is no JSON parser is bundled by default, so adding the
dependency to either class is arbitrary.


Regards!

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

EstebanLM

On 26 May 2015, at 18:40, Esteban A. Maringolo <[hidden email]> wrote:

Hi,

tl;dr: Question: Which JSON library is the "recommended" one?

STON will be integrated in Pharo 5.

and of course JSON is a subset of STON :)

Esteban



Long:
I'm modifying the PostgresV2 package to support JSON datatype but
instead of using the JSON package from PharoExtras I'm trying to use
NeoJSON.

The problem is no JSON parser is bundled by default, so adding the
dependency to either class is arbitrary.


Regards!

Esteban A. Maringolo


Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Guillermo Polito
And even if STON is integrated, PostgresV2 configuration should include a dependency against it  (because in the not so remote future we will need explicit dependency information to build images).

El mar., 26 de may. de 2015 a la(s) 6:55 p. m., Esteban Lorenzano <[hidden email]> escribió:
On 26 May 2015, at 18:40, Esteban A. Maringolo <[hidden email]> wrote:

Hi,

tl;dr: Question: Which JSON library is the "recommended" one?

STON will be integrated in Pharo 5.

and of course JSON is a subset of STON :)

Esteban



Long:
I'm modifying the PostgresV2 package to support JSON datatype but
instead of using the JSON package from PharoExtras I'm trying to use
NeoJSON.

The problem is no JSON parser is bundled by default, so adding the
dependency to either class is arbitrary.


Regards!

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Esteban A. Maringolo
2015-05-26 14:14 GMT-03:00 Guillermo Polito <[hidden email]>:
> And even if STON is integrated, PostgresV2 configuration should include a
> dependency against it  (because in the not so remote future we will need
> explicit dependency information to build images).

The '2.4-baseline' of ConfigurationOfPostgresV2 currently has a
dependency to a JSON package (~PharoExtras/JSON).

Current implementation is pretty static. I'm trying to work out a
refactoring so you can configure which parser to use when dealing with
JSON datatype in PostgreSQL. The "batteries included, but swappable"
approach (@Docker dixit).

It could be dead simple as specifying the class if the different JSON
libraries shared a common to/from API selectors, but they don't.

Regards!


Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Stephan Eggermont-3
In reply to this post by Esteban A. Maringolo
On 26/05/15 18:40, Esteban A. Maringolo wrote:
> I'm modifying the PostgresV2 package to support JSON datatype but
> instead of using the JSON package from PharoExtras I'm trying to use
> NeoJSON.

Is there a specific reason not to move to PostgresV3?

Stephan



Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Esteban A. Maringolo
2015-05-26 16:15 GMT-03:00 Stephan Eggermont <[hidden email]>:
> On 26/05/15 18:40, Esteban A. Maringolo wrote:
>>
>> I'm modifying the PostgresV2 package to support JSON datatype but
>> instead of using the JSON package from PharoExtras I'm trying to use
>> NeoJSON.

> Is there a specific reason not to move to PostgresV3?

I'd love to do so. But where is it? It is not in SmalltalkHub certainly.
It would also require to adapt/implement GLORP's adaptor for PostgresV3.
Or is it a plug-in replacement?

Please provide me with pointers, now is when :)


Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Sven Van Caekenberghe-2
In reply to this post by Esteban A. Maringolo

> On 26 May 2015, at 19:24, Esteban A. Maringolo <[hidden email]> wrote:
>
> It could be dead simple as specifying the class if the different JSON
> libraries shared a common to/from API selectors, but they don't.

Yes, it would be very good if there was such a thing as a common API for any reader/writer of any format (JSON, CSV, XML, STON, FUEL, ...).

For a reader that is pretty easy, I think. Any reader object should understand

 #readFrom: <stream> (binary or character ReadStream as appropriate)

And maybe also

 #readFromString: <string>
 #readFromBytes: <bytearray>

For the writer, I am not so sure. Maybe

 #nextPut: <object> toStream: <stream> (binary or character ReadStream as appropriate)

And maybe also

 #toString: <object>
 #toBytes: <object>

Note that the reader and writer objects could be different.

But like I said, I am not so sure about the API. We could try to define a Trait for this.

Sven


Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

NorbertHartl

> Am 26.05.2015 um 21:42 schrieb Sven Van Caekenberghe <[hidden email]>:
>
>
>> On 26 May 2015, at 19:24, Esteban A. Maringolo <[hidden email]> wrote:
>>
>> It could be dead simple as specifying the class if the different JSON
>> libraries shared a common to/from API selectors, but they don't.
>
> Yes, it would be very good if there was such a thing as a common API for any reader/writer of any format (JSON, CSV, XML, STON, FUEL, ...).
>
> For a reader that is pretty easy, I think. Any reader object should understand
>
> #readFrom: <stream> (binary or character ReadStream as appropriate)
>
> And maybe also
>
> #readFromString: <string>
> #readFromBytes: <bytearray>
>
> For the writer, I am not so sure. Maybe
>
> #nextPut: <object> toStream: <stream> (binary or character ReadStream as appropriate)
>
> And maybe also
>
> #toString: <object>
> #toBytes: <object>
>
> Note that the reader and writer objects could be different.
>
> But like I said, I am not so sure about the API. We could try to define a Trait for this.
>
I'd like to have #readFrom:as: . Some of the mappers instantiate common classes that should be overwritable. Of course this does not apply for e.g. fuel.

Norbert



Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Sven Van Caekenberghe-2

> On 26 May 2015, at 21:54, Norbert Hartl <[hidden email]> wrote:
>
>>
>> Am 26.05.2015 um 21:42 schrieb Sven Van Caekenberghe <[hidden email]>:
>>
>>
>>> On 26 May 2015, at 19:24, Esteban A. Maringolo <[hidden email]> wrote:
>>>
>>> It could be dead simple as specifying the class if the different JSON
>>> libraries shared a common to/from API selectors, but they don't.
>>
>> Yes, it would be very good if there was such a thing as a common API for any reader/writer of any format (JSON, CSV, XML, STON, FUEL, ...).
>>
>> For a reader that is pretty easy, I think. Any reader object should understand
>>
>> #readFrom: <stream> (binary or character ReadStream as appropriate)
>>
>> And maybe also
>>
>> #readFromString: <string>
>> #readFromBytes: <bytearray>
>>
>> For the writer, I am not so sure. Maybe
>>
>> #nextPut: <object> toStream: <stream> (binary or character ReadStream as appropriate)
>>
>> And maybe also
>>
>> #toString: <object>
>> #toBytes: <object>
>>
>> Note that the reader and writer objects could be different.
>>
>> But like I said, I am not so sure about the API. We could try to define a Trait for this.
>>
> I'd like to have #readFrom:as: . Some of the mappers instantiate common classes that should be overwritable. Of course this does not apply for e.g. fuel.
>
> Norbert

Hmm, that would become quickly much more complex than I intended it to be. More complex configuration should be done up front when you configure the reader or writer object, I think.

The idea is to find a usage common API.



Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

NorbertHartl

> Am 26.05.2015 um 22:13 schrieb Sven Van Caekenberghe <[hidden email]>:
>
>
>> On 26 May 2015, at 21:54, Norbert Hartl <[hidden email]> wrote:
>>
>>>
>>> Am 26.05.2015 um 21:42 schrieb Sven Van Caekenberghe <[hidden email]>:
>>>
>>>
>>>> On 26 May 2015, at 19:24, Esteban A. Maringolo <[hidden email]> wrote:
>>>>
>>>> It could be dead simple as specifying the class if the different JSON
>>>> libraries shared a common to/from API selectors, but they don't.
>>>
>>> Yes, it would be very good if there was such a thing as a common API for any reader/writer of any format (JSON, CSV, XML, STON, FUEL, ...).
>>>
>>> For a reader that is pretty easy, I think. Any reader object should understand
>>>
>>> #readFrom: <stream> (binary or character ReadStream as appropriate)
>>>
>>> And maybe also
>>>
>>> #readFromString: <string>
>>> #readFromBytes: <bytearray>
>>>
>>> For the writer, I am not so sure. Maybe
>>>
>>> #nextPut: <object> toStream: <stream> (binary or character ReadStream as appropriate)
>>>
>>> And maybe also
>>>
>>> #toString: <object>
>>> #toBytes: <object>
>>>
>>> Note that the reader and writer objects could be different.
>>>
>>> But like I said, I am not so sure about the API. We could try to define a Trait for this.
>>>
>> I'd like to have #readFrom:as: . Some of the mappers instantiate common classes that should be overwritable. Of course this does not apply for e.g. fuel.
>>
>> Norbert
>
> Hmm, that would become quickly much more complex than I intended it to be. More complex configuration should be done up front when you configure the reader or writer object, I think.
>
> The idea is to find a usage common API.
>
Agreed somehow :)

Norbert



Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Esteban A. Maringolo
In reply to this post by Sven Van Caekenberghe-2
2015-05-26 16:42 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
>> On 26 May 2015, at 19:24, Esteban A. Maringolo <[hidden email]> wrote:
>> It could be dead simple as specifying the class if the different JSON
>> libraries shared a common to/from API selectors, but they don't.

> Yes, it would be very good if there was such a thing as a common API for any reader/writer of any format (JSON, CSV, XML, STON, FUEL, ...).
>
> For a reader that is pretty easy, I think. Any reader object should understand
>
>  #readFrom: <stream> (binary or character ReadStream as appropriate)

+1

> And maybe also
>
>  #readFromString: <string>

It could be implemented using #readFrom:

>  #readFromBytes: <bytearray>

This should also specify encoding, I think.


> For the writer, I am not so sure. Maybe
>  #nextPut: <object> toStream: <stream> (binary or character ReadStream as appropriate)

> And maybe also
>  #toString: <object>

In this particular case it is all what I'd need, #fromString:/toString:

>  #toBytes: <object>

> Note that the reader and writer objects could be different.

This is also a requirement, particularly if you want to use NeoJSON/CSV

> But like I said, I am not so sure about the API. We could try to define a Trait for this.

I think it's more an Interface/protocol (contract) rather than a trait.
But maybe because I don't know how a trait could be implemented to solve this.

Regards!

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Levente Uzonyi-2
In reply to this post by Esteban A. Maringolo
On Tue, 26 May 2015, Esteban A. Maringolo wrote:

> 2015-05-26 16:15 GMT-03:00 Stephan Eggermont <[hidden email]>:
>> On 26/05/15 18:40, Esteban A. Maringolo wrote:
>>>
>>> I'm modifying the PostgresV2 package to support JSON datatype but
>>> instead of using the JSON package from PharoExtras I'm trying to use
>>> NeoJSON.
>
>> Is there a specific reason not to move to PostgresV3?
>
> I'd love to do so. But where is it? It is not in SmalltalkHub certainly.

Google is your friend in this case. It's on squeaksource.com, but I also
saw a Pharo port on Github.

> It would also require to adapt/implement GLORP's adaptor for PostgresV3.
> Or is it a plug-in replacement?

It has slightly different API than the V2 version. I've never used Glorp,
so I can't tell if it works or not, but I assume that it does not.

Levente

>
> Please provide me with pointers, now is when :)
>
>
> Esteban A. Maringolo
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Stephan Eggermont-3
In reply to this post by Esteban A. Maringolo
On 26-05-15 21:37, Esteban A. Maringolo wrote:

> 2015-05-26 16:15 GMT-03:00 Stephan Eggermont <[hidden email]>:
>> On 26/05/15 18:40, Esteban A. Maringolo wrote:
>>>
>>> I'm modifying the PostgresV2 package to support JSON datatype but
>>> instead of using the JSON package from PharoExtras I'm trying to use
>>> NeoJSON.
>
>> Is there a specific reason not to move to PostgresV3?
>
> I'd love to do so. But where is it? It is not in SmalltalkHub certainly.
> It would also require to adapt/implement GLORP's adaptor for PostgresV3.
> Or is it a plug-in replacement?
>
> Please provide me with pointers, now is when :)

Source is http://www.squeaksource.com/PostgresV3

Some discussions

http://forum.world.st/Status-of-PostgresV3-td4780110.html

http://forum.world.st/Parsing-SQL-in-a-Pharo-system-td4781777.html#a4781896

http://forum.world.st/Prepared-Statements-on-PostgresV2-td4798714.html#a4798825

(older)
http://forum.world.st/status-of-PostgresV3-package-td3600415.html

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

stepharo
In reply to this post by Guillermo Polito


Le 26/5/15 19:14, Guillermo Polito a écrit :
> And even if STON is integrated, PostgresV2 configuration should
> include a dependency against it  (because in the not so remote future
> we will need explicit dependency information to build images).

+ 1000000

Mking dependencies explicit is the only way to not die under complexity!

Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

stepharo
In reply to this post by Esteban A. Maringolo


Le 26/5/15 18:40, Esteban A. Maringolo a écrit :

> Hi,
>
> tl;dr: Question: Which JSON library is the "recommended" one?
>
>
> Long:
> I'm modifying the PostgresV2 package to support JSON datatype but
> instead of using the JSON package from PharoExtras I'm trying to use
> NeoJSON.
>
> The problem is no JSON parser is bundled by default, so adding the
> dependency to either class is arbitrary.

Why declaring a dependency would be a bad idea.
You use then declare it!
>
>
> Regards!
>
> Esteban A. Maringolo
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Esteban A. Maringolo
2015-05-28 3:41 GMT-03:00 stepharo <[hidden email]>:
>> The problem is no JSON parser is bundled by default, so adding the
>> dependency to either class is arbitrary.
> Why declaring a dependency would be a bad idea.
> You use then declare it!

I didn't say "bad", I said "arbitrary". :)

Otherwise I'm establishing a personal preference of a particular
library, that isn't directly replaceable by other of the user
preference. I like to provide a reasonable default, but keep options
open. :)

Regards!


Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Is there an official JSON parser/writer?

Stephan Eggermont-3
On 28-05-15 16:42, Esteban A. Maringolo wrote:

> 2015-05-28 3:41 GMT-03:00 stepharo <[hidden email]>:
>>> The problem is no JSON parser is bundled by default, so adding the
>>> dependency to either class is arbitrary.
>> Why declaring a dependency would be a bad idea.
>> You use then declare it!
>
> I didn't say "bad", I said "arbitrary". :)
>
> Otherwise I'm establishing a personal preference of a particular
> library, that isn't directly replaceable by other of the user
> preference. I like to provide a reasonable default, but keep options
> open. :)

Well, we know how to do groups and a compatibility layer...
It's just that we would want a CI build for every group.

Stepham