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 <javascript:_e({}, 'cvml',
> 'web2py%2bunsubscr...@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.
