8

Does SignalR support payloads other than those containing JSON or Text like BSON, etc.

sgtz
  • 8,849
  • 9
  • 51
  • 91
  • anything new on this topic? protobuf as a serializer could be worth implementing!? – esskar Apr 21 '13 at 18:05
  • @esskar: I may explore this in the future, possibly as an open source project, but can't right now. The appetite appears to be low. One comment worth considering is that text based protocols get compression in the browser. – sgtz Apr 22 '13 at 04:31
  • thats true: but compression costs time, and deserialising json compared to protobuf is slower - at least due to the fact that numbers are encoded as strings in json. and if one needs to send bytes, there is the overhead of base64 as well. – esskar Apr 22 '13 at 09:53
  • @esskar: I agree 100%. My compromise right now is protobuf for mobile, and json for JavaScript. Annoyingly, JSON based libs such as BreezeJs has some features that I like (which could be implemented via protobuf too)... but which aren't right now (and probably wont be). These days, I'm trying not to make decisions based on community, and not just because I think it's better technically. – sgtz Apr 22 '13 at 13:42

1 Answers1

3

Out of the box? No. By default SignalR only supports JSON. However, it being open source/a framework you can quite easily make small modifications (an adapter) to support other formats on your own.

N. Taylor Mullen
  • 18,061
  • 6
  • 49
  • 72
  • has it been designed with other serialization methods in mind? – sgtz Dec 04 '12 at 20:07
  • You can provide your own serializer via the DependencyResolver. Granted they currently need to implement IJsonSerializer. You could go as far as to slightly modify the dependencyresolver to accept an ISerializer (You'd create this class) and then create your own serializer based on payload type. The Hardest part of this process would be modifying the client to accept the new format. Currently SignalR takes a dependency on JSON.Net so if you choose a supported format via JSON.net it may make the process easier. Keep in mind, by going with another format you will lose message compression =) – N. Taylor Mullen Dec 04 '12 at 23:04
  • So far I've only seen string support, whereas ashx can support anything. Thanks for mentioning the compression angle. One problem I'm facing is the VS2012 in-place replacement of the v4 assemblies. As a result, can't install VS2012 here :( Also, object Parse(string json, Type targetType) -- it only accepts string. byte[] would be useful. – sgtz Dec 05 '12 at 09:49
  • Not being able to install VS2012 is definitely an issue, especially if you're looking at modifying SignalR source. – N. Taylor Mullen Dec 05 '12 at 18:26
  • ...and on making byte[] a valid payload? I'll take a look at dependencyresolver I guess. Looks like I need an extra dev machine. Any idea on the apetite for other serializers in the community? Worth doing extensions open source? – sgtz Dec 05 '12 at 19:12
  • Passing byte's over the wire would require some more work to allow the WebSockets transport to utilize it. However, I'd recommend against sending bytes over the wire because you will not be able to use any of the other SignalR transports. As for other serializes in the community, i can't say I'm well versed but now a days JSON is probably #1. If you're up for creating a SignalR extension that allows for new payload methods I'm sure it wouldn't be looked down upon though =) – N. Taylor Mullen Dec 05 '12 at 20:05