Open usirin opened 7 years ago
This sounds great, this.ws
is not a great fit for sockjs
usage I agree. and +1k for renaming it to transport
but we need to make sure that existing users of kite doesn't rely on that property like https://github.com/koding/koding/blob/master/client/app/lib/kite/kodingkite.coffee#L59 it's a thing that can be fixed easily but there might be some other usages. Instead I think it's time for to make major changes like this in 2.0 branch.
Current kite client implementation is tightly coupled with
websocket
transform, the transport object it's using is assigned tokite.ws
property. But we already have 2 different servers:websocket
sockjs
Since client implementation of these 2 servers are identical, only changing url to
ws://someurl
tohttp://someurl
satisfies the kite initialization/connection. This works until we want to support anothertransport
protocol which has different api characteristics (e.g: webrtc).We are already accepting
transformOptions
andtransformClass
via options onKite
initialization step. I propose extending this feature with following steps:transport
transport
by defining aKiteTransport
interface, and simply initialize giventransportClass
with giventransportOptions
without any explicit check like we currently do here:KiteTransport
interface i imaginedWebSocketTransport
class would be like the following:and to initialize a kite using this transport i would use it just as before:
Kite
api to accept atransports
option allowing us to register multiple transports (please note these code snippets are just imaginary code as a brain storm, not sure how feasible it would be to implement these):The aim here is to allow us using multiple transports without touching any of the existing kite code. I am still not sure how
url
would work in the scenario where we have multiple transports.To sum up, since
ws
is used internal-only, (1) replacing it with atransport
property can be done without introducing a breaking change. (2) extending kite api to accept multiple transports should be done once we are satisfied with the api and the way it's gonna work, therefore it implicitly depends on (1).In the future i see several
kite-server-<transport>
packages exporting bothServer
classes and theirTransport
classes to be used by clients.@gokmen thoughts?