Add support for NSKeyedArchiver

[cnstoll]

We plan to add support for NSKeyedArchiver by checking the contents of the passed message. If the contents can be serialized as JSON they will be. If not, they will fall back to NSKeyedArchiver/NSCoding support.

[martinblech]

I wonder, why don't you use NSKeyedArchiver/NSCoding directly instead, and skip JSON altogether?

[cnstoll]

A valid question. To some extent, I think you could consider the contract you create between your app and your extension as a series of web service endpoints. Technically, it's not the same thing but philosophically it is. That's actually how I've started thinking about it while using this library in my apps. JSON is the natural choice if you think about it that way.

I could also envision a case where someone fetched a JSON object from a real web service and wanted to use it directly to populate the UI on their extension. This feature of JSON message passing supports that use case, and others.

I'd love to hear other opinions here too. I'd prefer to support both JSON and NSCoding. I honestly think that it could have gotten by without NSCoding, but once @RCacheaux suggested it it seemed like such an obvious alternative that people would find a use for that I decided to add it as well.

[martinblech]

Thank you @cnstoll for sharing your thoughts about this.

I could also envision a case where someone fetched a JSON object from a real web service and wanted to use it directly to populate the UI on their extension. This feature of JSON message passing supports that use case, and others.

In this case, you can still pass the message using NSCoding anyway. I could be wrong, but I think that all valid JSON objects are also NSCoding compliant (NSDictionary, NSArray, NSNumber, NSString). This doesn't hold true the other way around (NSDate, for example).

I submitted pull request #5 in case you want to consider this option.

[esttorhe]

To be honest I would rather have the option to decide how I would like my objects to be serialized.

Truth be told (even though it might be "against" "natural" Cocoa coding) it feels more natural to use JSON maybe because of how we are used to consume APIs (I could be wrong).

I think maybe an approach like AFNetworkingRequestSerializer (holds truth for response serializer as well) where it defaults to JSON (if I remember correctly) but one could provide another serializer (could even support a custom serializer; although that might be too far away from the scope of this issue).

My 2 cents on the matter; I'll try to find some time and will try to add the custom serializer "a la" AFNetworking approach.

[martinblech]

I think that AFNetworking's extensible approach to serializers makes sense because in their context because it's a client-side library that is meant to integrate with third party server-side REST APIs that use different formats.

With MMWormhole it's a different story, it's the same library that is in control of both ends of the communication, so users don't really need to see how it's serialized internally. I don't think that the added complexity of having multiple serialization formats is justified in this case.

The main blocker that I see with the current JSON serialization is that it doesn't handle instances of NSDate. Besides NSKeyedArchiver, there's also FastCoding, which is fast and supports many more classes.

[esttorhe]

With MMWormhole it's a different story, it's the same library that is in control of both ends of the communication, so users don't really need to see how it's serialized internally

While that's true its also true that if you are developing both ends is up to you if you want to use JSON or NSCoding and having the ability to let you choose would benefit many more developers than "forcing" a format for all.

Following your comment having a custom serializer approach would let you use FastCoding if you desire it while @cnstoll can keep using JSON as he initially intended the "framework" to work.

I don't think that the added complexity of having multiple serialization formats is justified in this case.

So I would have to disagree with that comment because I can see a far great benefit from having multiple serialization options; IMHO.

I'll try to work on that tomorrow and will make a PR ASAP; we can then see if it fits in the current architecture if not no harm done rejecting the PR.

[martinblech]

I see your point @esttorhe. At first sight I didn't see much value in having mutliple serialization formats, but then I might be wrong.

Another option would be for MMWormhole to stay simple and provide a "raw" API where users can pass instances of NSData, leaving the serialization completely up to them.

[cnstoll]

This is a great discussion. Thanks ya'll!

What I love about the current public interface here is that you don't really need to care about how your messages are serialized. As was already mentioned, because the same library manages both sides of the wormhole, the serialization format is almost irrelevant to the user. File system serialization can be a black box if we want it to be. If you follow that logic, then whether or not messages are serialized into a JSON data format to disk or a archive data format to disk doesn't matter. The most important thing is to support passing in either data type, which this does.

The question I am now trying to answer is whether or not there is a case where the user would care what format the data is that is written to disk. The only difference I see between writing a JSON file and an archive file is that you could open the JSON file in a text editor on your Mac and read it's contents plain as anything. I could see that potentially being valuable for development/debugging. But then again, if MMWormhole does it's job well, you should also never need to do that.

I'm actually leaning towards going forward with only NSKeyedArchiver as the data serializer, while still obviously supporting both JSON and NSCoding compliant objects that are passed in as messages. For what it's worth, I would likely continue using the library exactly as the examples state, with dictionaries containing strings/numbers. But I like the idea of keeping the file system functionality simple, which this would do.

Anyone have any thoughts on this one way or the other?

Thanks,

• Conrad

[cnstoll]

I decided to go with Martin's suggestion of straight up NSKeyedArchiver for serialization. I view serialization on MMWormhole mostly as an implementation detail. The most important thing is the format of messages it supports, not how they're written to disk. Since NSKeyedArchiver supports JSON message objects, I like the simplicity of defaulting to that as the serialization mechanism.

Thanks everyone for weighing in on this!

[martinblech]

@cnstoll thank you for taking my feedback, I'm happy to see MMWormhole moving forward!