-
Notifications
You must be signed in to change notification settings - Fork 0
Architecture considerations #13
Comments
/cc @pedroscaff @LukasJue |
First of all, I think everything about management, where you don't draw, but need information about the session should be in the HTTP-API, and everything that is important to the users in real time or while drawing should belong to the websocket. I really would like, to keep that websocket-stream free of data, that could also be delivered asynchronously. For your second point: I think we should keep it simple. I mean, your suggestions are good, but they would lose the scope of drawr. Let me explain that: we want an simple API so that everyone can make an application for drawr, and HTTP is supported by so many frameworks. If we use maybe advanced, but less supported, technology for our API, we increase the obstacles for beginners. I really would like to enlarge our API, instead of making it more efficient. But that's an tough decision... How big do you estimate the benefit from an RPC-Protocol? @robertgzr For the messageformat I'm not sure... First of all, we want to send as less useless (and by useless i mean redundant) data as possible. So when a technology helps us, to reduce redundant information, I'm likely to support that. But on the other hand, every programming language that could be interesting for drawr has an JSON API. I can see, that Protobuf has a growing collection of supported languages, that cover most usecases I can think of, but I know there are usecases, I can't even think of. I don't want to reduce our potential. |
The only components involved with it are the server (Go) and the library (JS) (both of which have protobuf libraries). And even if it would be necessary Java and ObjC are supported as well. And like for 2. using protobuf reduces the implementation overhead because we only need to work out a spec and can then just generate the interfaces. |
Current
master
implementationuses HTTP API calls for basic session interaction/management
/session/new
returns a new session id/session/<session_ulid>/ws
to start websocket connectionQuestions
http://blog.u2i.com/we-made-a-multiplayer-browser-game-in-go-for-fun/
The text was updated successfully, but these errors were encountered: