Is there an official JSON parser/writer?
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
On 26 May 2015, at 18:40, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi,
tl;dr: Question: Which JSON library is the "recommended" one?
STON will be integrated in Pharo 5. https://github.com/svenvc/ston/blob/master/ston-paper.md <https://github.com/svenvc/ston/blob/master/ston-paper.md> 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
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 < estebanlm@gmail.com> escribió:
On 26 May 2015, at 18:40, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi,
tl;dr: Question: Which JSON library is the "recommended" one?
STON will be integrated in Pharo 5. https://github.com/svenvc/ston/blob/master/ston-paper.md
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
2015-05-26 14:14 GMT-03:00 Guillermo Polito <guillermopolito@gmail.com>:
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
On 26 May 2015, at 19:24, Esteban A. Maringolo <emaringolo@gmail.com> 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
Am 26.05.2015 um 21:42 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 26 May 2015, at 19:24, Esteban A. Maringolo <emaringolo@gmail.com> 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
On 26 May 2015, at 21:54, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.05.2015 um 21:42 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 26 May 2015, at 19:24, Esteban A. Maringolo <emaringolo@gmail.com> 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.
Am 26.05.2015 um 22:13 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 26 May 2015, at 21:54, Norbert Hartl <norbert@hartl.name> wrote:
Am 26.05.2015 um 21:42 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 26 May 2015, at 19:24, Esteban A. Maringolo <emaringolo@gmail.com> 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
2015-05-26 16:42 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 26 May 2015, at 19:24, Esteban A. Maringolo <emaringolo@gmail.com> 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
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!
2015-05-26 16:15 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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
On Tue, 26 May 2015, Esteban A. Maringolo wrote:
2015-05-26 16:15 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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
On 26-05-15 21:37, Esteban A. Maringolo wrote:
2015-05-26 16:15 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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#a4798... (older) http://forum.world.st/status-of-PostgresV3-package-td3600415.html Stephan
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
2015-05-28 3:41 GMT-03:00 stepharo <stepharo@free.fr>:
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
On 28-05-15 16:42, Esteban A. Maringolo wrote:
2015-05-28 3:41 GMT-03:00 stepharo <stepharo@free.fr>:
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
participants (8)
-
Esteban A. Maringolo -
Esteban Lorenzano -
Guillermo Polito -
Levente Uzonyi -
Norbert Hartl -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe