Re: [web2py] Re: pyDAL -> jsDAL?

2019-04-30 Thread António Ramos 
If vuejs is the way to go (thank you massimo for the choice...) i think it
should evolve also to vuex for client store and use something like this for
persistence.
https://flaviocopes.com/vuex-persist-localstorage/
I think we can kill 2 rabbits with just one bullet...

Em ter, 30 de abr de 2019 às 12:42, villas  escreveu:

> Hi Scott
>
> It's probably unrealistic to imagine that a proper DB would be stored
> locally.  I mean, where would its contents come from?  If the answer is a
> remote DB, then you are already back at square one.
>
> However, it still makes sense to cache data on the client side. When the
> cache gets larger,  it makes sense to think more about Local Storage.  But
> we already have that now.
> 
>
> The main obstacle for local storage is keeping the data fresh,  and that
> includes the user himself updating it.
>
> Most of the logic leads us back to web services, REST interfaces and DBs
> in the 'cloud'.  I guess that's where we're all heading!
>
> Regards,  D
>
>
>
> On Tuesday, 30 April 2019 01:47:36 UTC+1, Scott Hunter wrote:
>>
>>
>> The direction from web2py to web3py seems to be applications where the
>> server is responsible for (relatively) static pages which use Javascript
>> for their dynamic aspects & talking to the server via an API, primarily for
>> interaction w/ the database.
>>
>> In the spirit of Progressive Web Apps, one could imagine getting to the
>> point where instead of making calls to the server, Javascript functions are
>> called instead to interact w/ an SQLite DB under the browser's control.
>> Doing so via something like pyDAL, but replacing Python with Javascript &
>> only needing to support SQLite would not only ease the burden of writing
>> such code, but make it easier to make a transition between these two DB
>> locations.
>>
>> I'm actually thinking specifically of being able to deploy a pared-down
>> version of a "normal" application which could perform most of its
>> functionality off-line, and use online access only for transferring
>> information in bulk between the local DB and the one in the cloud.  The
>> more that those applications can share code, the better.  (I've
>> accomplished this goal, somewhat clunkily, by deploying the web2py binary
>> w/ a limited version of the app in the cloud; an approach as I've described
>> above seems that it wouldn't be nearly as brittle.)
>>
>> Does this make any sense?  Would something like a jsDAL be prohibitively
>> difficult to write, or not really worth the effort?
>>
> --
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> ---
> 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/d/optout.
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
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/d/optout.

[web2py] Re: pyDAL -> jsDAL?

2019-04-30 Thread villas 
Hi Scott

It's probably unrealistic to imagine that a proper DB would be stored 
locally.  I mean, where would its contents come from?  If the answer is a 
remote DB, then you are already back at square one.

However, it still makes sense to cache data on the client side. When the 
cache gets larger,  it makes sense to think more about Local Storage.  But 
we already have that now. 


The main obstacle for local storage is keeping the data fresh,  and that 
includes the user himself updating it.

Most of the logic leads us back to web services, REST interfaces and DBs in 
the 'cloud'.  I guess that's where we're all heading!

Regards,  D  



On Tuesday, 30 April 2019 01:47:36 UTC+1, Scott Hunter wrote:
>
>
> The direction from web2py to web3py seems to be applications where the 
> server is responsible for (relatively) static pages which use Javascript 
> for their dynamic aspects & talking to the server via an API, primarily for 
> interaction w/ the database.
>
> In the spirit of Progressive Web Apps, one could imagine getting to the 
> point where instead of making calls to the server, Javascript functions are 
> called instead to interact w/ an SQLite DB under the browser's control. 
>  Doing so via something like pyDAL, but replacing Python with Javascript & 
> only needing to support SQLite would not only ease the burden of writing 
> such code, but make it easier to make a transition between these two DB 
> locations.
>
> I'm actually thinking specifically of being able to deploy a pared-down 
> version of a "normal" application which could perform most of its 
> functionality off-line, and use online access only for transferring 
> information in bulk between the local DB and the one in the cloud.  The 
> more that those applications can share code, the better.  (I've 
> accomplished this goal, somewhat clunkily, by deploying the web2py binary 
> w/ a limited version of the app in the cloud; an approach as I've described 
> above seems that it wouldn't be nearly as brittle.)
>
> Does this make any sense?  Would something like a jsDAL be prohibitively 
> difficult to write, or not really worth the effort?
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
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/d/optout.

[web2py] Re: pyDAL -> jsDAL?

2019-04-30 Thread Anthony 
There is no SQLite in the browser, unless you are talking about something 
like https://github.com/kripken/sql.js, though that is very heavy and is 
in-memory only. There are a number of packages that provide an abstraction 
over IndexedDB, such as Dexie.js, AlaSQL, Nano-SQL, Lovefield, etc. Maybe 
have a look at their codebases to get a sense of the complexity involved.

Anthony

On Monday, April 29, 2019 at 8:47:36 PM UTC-4, Scott Hunter wrote:
>
>
> The direction from web2py to web3py seems to be applications where the 
> server is responsible for (relatively) static pages which use Javascript 
> for their dynamic aspects & talking to the server via an API, primarily for 
> interaction w/ the database.
>
> In the spirit of Progressive Web Apps, one could imagine getting to the 
> point where instead of making calls to the server, Javascript functions are 
> called instead to interact w/ an SQLite DB under the browser's control. 
>  Doing so via something like pyDAL, but replacing Python with Javascript & 
> only needing to support SQLite would not only ease the burden of writing 
> such code, but make it easier to make a transition between these two DB 
> locations.
>
> I'm actually thinking specifically of being able to deploy a pared-down 
> version of a "normal" application which could perform most of its 
> functionality off-line, and use online access only for transferring 
> information in bulk between the local DB and the one in the cloud.  The 
> more that those applications can share code, the better.  (I've 
> accomplished this goal, somewhat clunkily, by deploying the web2py binary 
> w/ a limited version of the app in the cloud; an approach as I've described 
> above seems that it wouldn't be nearly as brittle.)
>
> Does this make any sense?  Would something like a jsDAL be prohibitively 
> difficult to write, or not really worth the effort?
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
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/d/optout.