I would like to begin work on implementing NSJSONSerialization. I believe that to get this up and running quickly, it would be prudent to vendor jsmn () within Foundation so we can quickly provide an implementation which will be crucial to web server support, instead of writing our own tokenizer in Swift, though this would definitely be a worthwhile long term goal.
My questions are:
Would it be appropriate to vendor this library either as a static lib, or even better, within the target itself?
Would there be an objection to adding MIT licensed code to the OSS Foundation?
If the answer to these questions is yes, then I will begin immediately, but I’d like to hear from someone in the core team about it.
On 4 Dec 2015, at 13:33, swizzlr <me@swizzlr.co> wrote:
I would like to begin work on implementing NSJSONSerialization. I believe that to get this up and running quickly, it would be prudent to vendor jsmn () within Foundation so we can quickly provide an implementation which will be crucial to web server support, instead of writing our own tokenizer in Swift, though this would definitely be a worthwhile long term goal.
My questions are:
Would it be appropriate to vendor this library either as a static lib, or even better, within the target itself?
Would there be an objection to adding MIT licensed code to the OSS Foundation?
If the answer to these questions is yes, then I will begin immediately, but I’d like to hear from someone in the core team about it.
A few weeks ago I wrote a pure-Swift JSON parsing library. It actually
uses an enum for the JSON types instead of objects, but it's split into
two components, the first is an event-based parser and the second is the
decoder that actually turns the events into the JSON enum. This means
that a trivial decoder can be written for the event-based stream that
emits plist objects instead of the JSON enum. Performance is decent, in
my tests it takes around 2.5-3x slower than NSJSONSerialization, but it
can probably be optimized a bit now that the Swift source is available
(or maybe the Swift stdlib can be optimized in certain relevant areas).
There's no encoder, but that's a lot easier to write than a decoder. The
event-stream parser itself operates over a sequence of UnicodeScalars
(and I have a helper that produces a UnicodeScalar stream from an NSData
to make parsing that easy).
The only real trouble I have with that is that, unfortunately,
dispatch_data_t does not have an external iterator for any subdata
blocks, and the internal iterator cannot be converted into an external
iterator (so it cannot be used to produce a
SequenceType<UnicodeScalar>), and furthermore the UTF8 type cannot
handle switching generators mid-stream (especially if one iterator only
yields part of a code point), which means that converting a
non-contiguous NSData to a sequence is going to have to copy all the
subdatas into one contiguous block. I'm unsure if this is particularly
meaningful though, for any non-pathological JSON response, as most
real-world JSON responses probably fit into a single packet and
therefore will likely already be contiguous in memory when decoded.
My library does not yet have an encoder, but it should be pretty easy to
write one (it can be based on the same event stream model).
If interested, I'd be happy to donate the library to the Swift project
to use as a basis for NSJSONSerialization (and hopefully even for a
non-object-based JSON API, e.g. the aforementioned enum). It's not
currently public, because I haven't actually written much in the way of
tests yet and I wanted to test it out in a real-world project before
releasing to the world (which was going to happen over the next few
weeks), but I can make it public now if there's interest in seeing it.
-Kevin Ballard
···
On Fri, Dec 4, 2015, at 05:33 AM, swizzlr wrote:
Sorry, forgot to include the link:
https://zserge.com/jsmn/
> On 4 Dec 2015, at 13:33, swizzlr <me@swizzlr.co> wrote:
>
> I would like to begin work on implementing NSJSONSerialization. I believe that to get this up and running quickly, it would be prudent to vendor jsmn () within Foundation so we can quickly provide an implementation which will be crucial to web server support, instead of writing our own tokenizer in Swift, though this would definitely be a worthwhile long term goal.
>
> My questions are:
>
> Would it be appropriate to vendor this library either as a static lib, or even better, within the target itself?
> Would there be an objection to adding MIT licensed code to the OSS Foundation?
>
> If the answer to these questions is yes, then I will begin immediately, but I’d like to hear from someone in the core team about it.
>
> Best,
>
> Tom