Version du 19 novembre 2009 à 00:30 (modifier)
1001nuits (Discuter | Contributions)
← Différence précédente |
Version actuelle (9 décembre 2009 à 06:03) (modifier) (défaire)
1001nuits (Discuter | Contributions)
|
| Ligne 1 : |
Ligne 1 : |
| - | == Google Wave: Not the proper software architecture? == | + | #REDIRECT [[Google Wave architecture flaws]] |
| - | | + | |
| - | The problem of GW could be a problem of architecture. For me, GW is a trainee job :-) Let me explain my point : | + | |
| - | | + | |
| - | === Server side architecture === | + | |
| - | | + | |
| - | Wave is based on XMPP with is not really the kind of protocol I would have used to design such a tool (XML over IP designed for quick chat application with very low traffic and network footprint). | + | |
| - | | + | |
| - | Wave server is using XML documents for Wave which is really insane when it comes to parallel modifications. if you want to validate the XML, it will be slow. Else, you have to bypass the XML standard and invent an "optimization" protocol. This is a silly design option, for sure, because you can manipulate tree structures with multi-threaded concurrent accesses with high volume without it to be XML based... | + | |
| - | | + | |
| - | Scalability will consequently be a nightmare to ensure, above all with millions of users. This seems to me as not reachable. | + | |
| - | | + | |
| - | === Client side architecture === | + | |
| - | | + | |
| - | Sure, it is web based, even if it aims to look as a multi threaded GUI. This is insane and even the use of GWT with HTML 5 will not guarantee the non scalability of the model. Currently a wave with several hundreds wavelets is totally unusable. | + | |
| - | | + | |
| - | Sure, the document manipulation can be of some use, but I fear the browser based approach is not a good one. | + | |
| - | | + | |
| - | === Conclusion === | + | |
| - | | + | |
| - | Wave will be ok provided: | + | |
| - | * The server side chooses a data model that can be custom, easy, and support any heavy concurrent access programming model; | + | |
| - | * The server side should use TCP, HTTP probably but not XMPP which is not adapted because at the end of the day, the purpose will be to generate streams from the server to the clients in broadcast mode; Indeed, the streaming protocols should have been studied because this is probably the future: streaming data that are not video/sound related. * This is a kind of design to investigate (Google guyz, you know where to contact me lol). | + | |
| - | * The client side should be a portable GUI compiled over the OS for performance; | + | |
| - | * The system should be designed properly from day one but not being a patchwork of various codes developed in Google and reused (XMMP server, GTalk plugin in Gmail, GWT and other stuff). | + | |
| - | | + | |
| - | I think, but it is probably quite personal that the idea of melting mails/wikis/chats is a good one but it cannot be implemented this way. | + | |
| - | | + | |
| - | That's why it is really too slow - because it is a trainee's work working for a buzz company. | + | |
| - | | + | |
| - | | + | |
| - | [[Catégorie:English section]][[Catégorie:Draft]] | + | |
