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.
