Well, as for the database, there are obvious security issues and performance issues - I mean, having an open connection from all clients to a single back-end database is a pretty nutty prospect for most serious programmers... Just think about connection-count,you can't even do connection pooling on this... You basically need to have an extremely wide eventually-consistent replication-cluster in the cloud, with like thousands of instances... That's horribly inefficient. And in terms of security? Lot's of people are still reluctant to trust the browser for even simple things like client-side validation, you think that an open-connection to a back-end database is gonna fly with these kind of folks?
And as for No-SQL vs RDBM, well, again, it is a question of target-audience - it depends on the level of complexity of inter-relation in your use-case's data model, so as I said - complex data-model benefit way too much from RDBMs and gain so little from No-SQL that it is simply un-fit for them... But that's a different topic altogether. As for real-time synchronization, again, it may be implemented really well in derby/meteor today, but I forsee that there are going to be many such implementations for general use-cases. I think there is an extension/version of web-sockets that is aimed at p2p, so you can basically do it without any server at all, eventually. As for no-refresh updates of the web-browser, it has nothing to do with meteor/derby or even any kind of real-time app - it is a browser-extension, coupled with a client/server library, that monitors your file-savings of your code, and pushes updates to your development browser. There are many such solutions today for many kinds of browsers and serves - it was just easy to implement in node.js because it's all javascript on both ends... There is nothing fundamentally restricting from doing this with web2py - you can run an instance of node.js that basically only does "that" for you, and still use web2py for all other stuff... It can even be implemented inside web2py itself, with like a worker-thread or something... You can even write something like this yourself - basically poll on file-changes of your javascript code, and stream them over an open web-socket, and parse them on your clien-side code to update your existing page... In the p2p-web-socket future world, people could theoretically do crazy stuff with that between each-other... :) Pretty diabolical shit... On Thu, Apr 18, 2013 at 2:13 PM, António Ramos <ramstei...@gmail.com> wrote: > Nice comment but a minor correction. > In meteor the client only has in his local database the documents he is > allowed to read. > That solves the security issues on the client. > > What I like most in meteor is > Not having to refresh the browser on every change i make in code. > Not having to code web sockets to deal with data change. Here we save a > lot of code. > Having all clients update automatically on every data change made by some > client. > > For specific real time web apps I don't know a better option.but that's > just me. > > > > No dia Quinta-feira, 18 de Abril de 2013, Arnon > Marcusa.m.marcus@gmail.comescreveu: > >> Well, there is no "one-size-fit's-all", and there is never gonna be... >> >> Currently, expecting a direct-connection with the database from the >> client side, still raises many eye-brows, and (IMHO) rightfully so... >> But that is exactly the expectation that frameworks like meteor are >> having. >> Iy is not going to work in the foreseeable future, for many web-apps to >> hold their entire database on the client side... There are way too many >> things to consider when wanting to do that (security, privacy, >> authorization, resource-use, etc.). >> I also thing it's a mistake to assume the client-side even "needs" that, >> for most cases. >> As I said, the data-model that the client needs, is almost "always" very >> different to the data-model in the database. For simple and small >> web-sites, that may work out, but once you get pass a certain level of >> complexity, and have hundreds of inter-linking tables, then in most of >> these cases it would make no sense having an identical data model in the >> client - it would be horobly wastefull and inefficient to the point of >> being unusable. >> >> Also, the client-side is still very lacking in terms of options >> of handling and handling relational data-models. Web2py's DAL is a god-sent >> - it is an ORM that is second-to-none afaik. >> >> In short, it would fit a very, well, (ahm..) "boring" target-audience... >> (no offence...) >> Not for complex web-apps. >> >> I think you could achieve all the benefits of meteor/derby with a >> hybrid-solution. >> Generally, there is no problem with the idea of auto-synching data-models >> across clients - it is actually a very exciting prospect - it should just >> not be assumed to be applicable for the whole database, is an >> "all-or-nothing" kind of way. >> I see a better vision - a web-app that has compartmentalized views, each >> within it's own little MVC world, and it's own data-model which represent a >> small portion of the database, structured specifically for that view's >> needs. Each of these components can have streaming communication with other >> instances of that save view in other browsers of other users, as well as >> with n instance of that same data-model on a server somewhere, which will >> take care of eventual-consistency in the background with the back-end >> database. >> I predict that this would be the model that would emergent to be >> the dominant one - you already see glimpses of it - Google Wave was an >> example - even long before web-sockets and data-store on the client. The >> entire google-gear architecture was an attempt at making something like >> this. >> >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "web2py-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to web2py+unsubscr...@googlegroups.com. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "web2py-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/web2py/kXXr9xo_2tM/unsubscribe?hl=en. > To unsubscribe from this group and all its topics, send an email to > web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
