jkorous added a comment. Hi Sam, thanks for your feedback!
In general I agree that explicitly factoring out the transport layer and improving layering would be a good thing. Unfortunately it's highly probable that we'd like to drop JSON completely from XPC dispatch (XPC -> JSON -> ProtocolCallbacks -> JSON -> XPC) in not too distant future. (Please don't take this as a promise as our priorities might change but it's probable enough that I don't recommend to base any common abstraction on JSON.) I originally tried to create similar abstraction but ultimately gave up as it was way too complex. Not saying it's impossible or that I would not like to though! I basically see these different parts of the problem: 1. dispatch implementation I think that different dispatch implementations might be better kept separate without any common abstraction as it's not a lot of code and not much of opportunities for shared implementation - DispatcherCommon.h/cpp effectively vanishes in case we drop JSON from XPC dispatch. 2. LSP request deserialization Deserialization of LSP requests for different transport layers is easy - it's a single line of code (currently lambda wrapper in HandlerRegisterer) so it would be easy to parametrize this. 3. LSP response serialization This is where I failed. Basically I haven't found any nice way how to make it a part of transport layer interface. I could imagine having a set of response classes in Protocol.h and toXpc functions but still not sure what kind of interface to have for these in transport layer. Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D48559 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
