Open orwant opened 9 years ago
Would be really nice
Original issue reported on code.google.com by d.alvarez.debrot%crazy-development.com@gtempaccount.com
on 2011-02-18 08:34:02
In the case, the client is talking to a web server on the LAN without access to internet
(because of temporary failure), the vizualization API is not available anymore. This
is a really important limitation in our context.
Original issue reported on code.google.com by jmhermelin
on 2011-02-18 08:43:53
Slow internet connections and offline usage are key features for me. I'm using viz for
two projects (via GWT), but have to remove in both for each of the reasons. The serving
of js with cache private; max-age=0 doesn't help either (pay the cost on every startup,
jsapi is set to 1 hour max-age).
Original issue reported on code.google.com by ken.horn
on 2011-02-22 16:16:15
would be really great to see this feature implemented
Original issue reported on code.google.com by aserofeev
on 2011-02-22 16:25:55
Would like to put this product on a closed network for govt use. Cannot use as is.
Original issue reported on code.google.com by westwoodstom
on 2011-03-01 14:35:04
I am in the same position as comment 5. Great framework but unusable in current state
for closed networks.
Original issue reported on code.google.com by eliquious
on 2011-03-01 15:17:21
Same issue here : offline usage is a must-have feature for me.
Original issue reported on code.google.com by marc.polizzi
on 2011-03-01 15:32:17
I also want this issue to get resolved.
Original issue reported on code.google.com by muralikrishna50
on 2011-03-29 20:46:31
I need off-line use for moments when the remote libraries are off-line. Like a "plan
b"
Original issue reported on code.google.com by hugosetta
on 2011-05-23 17:58:28
This online restriction is a really bad news, as it is NOT clearly explained when you
use it. This is probably the reason why GWT visualization is not so spread and used,
although it's a great framework.
Can someone from google explicitly tells us if Google plans to change its terms or
not ?
Thanks
Original issue reported on code.google.com by juli1.bec
on 2011-06-16 14:18:36
@juli1, I think we're more likely to win the lottery than getting a statement from google
on this ;-)
Original issue reported on code.google.com by d.alvarez.debrot%crazy-development.com@gtempaccount.com
on 2011-06-16 16:35:03
Please allow offline use. We really need it ASAP.
Original issue reported on code.google.com by csdeepu
on 2011-06-28 12:58:04
Yes, yes please. I have been working on a page the contains a number of charts and
dashboards and from a performance pov sometimes its just too slow. Also if our internet
connection goes down, the office folk should still be able to use the charts/dashboards.
Original issue reported on code.google.com by GregoryNoSpamJohn
on 2011-11-03 07:17:40
I need this as well...this just became a no go with this api due to this problem
Original issue reported on code.google.com by davidj2k
on 2012-04-20 18:19:34
take this offline, we are ready to pay !
My organization doesn't like that that data is being sent to you guys , you know goverment
senstive stuff.
Original issue reported on code.google.com by hus.mhd
on 2012-11-14 08:11:43
for a professional development this is a must. I'm using another lib (against my will
because I LOVE the API) but, for several reasons (intranet restrictions, speed, data
confidenciality, reliability) I cannot work with an online solution.
I don't see the point of not release from times to times an offline version.
Original issue reported on code.google.com by qsebas
on 2013-08-06 15:07:37
This would have really helped me today faced with loads of "NetworkError: 502 Bad Gateway
- https://www.google.com/jsapi"
Original issue reported on code.google.com by artfulrobot
on 2013-10-01 16:25:51
Would have used it, but requiring an internet connection to https://www.google.com/
is an absolute no-go for almost every commercial software development. Sadly looking
for an alternative!
Original issue reported on code.google.com by dfreismuth
on 2013-10-12 13:57:55
+1 here.... Please change the priority of this issue!
Many users complaint about this!
Original issue reported on code.google.com by tiagorico
on 2014-04-04 14:35:24
+1 We would be happy to pay licensing even to be able to run locally
Original issue reported on code.google.com by jharby
on 2014-06-13 16:46:07
+1 users in china basically cannot consistently get access to it
Original issue reported on code.google.com by flyboys3000
on 2014-11-14 15:35:38
has anyone found a suitable graphing/charting alternative to google-visualization that
can be used offline (without an internet connection / connection to www.google.com)?
onetinsoldier@hotmail.com
Original issue reported on code.google.com by tantolic@capaccess.org
on 2014-12-30 17:22:28
Use http://d3js.org/ or http://c3js.org/
Original issue reported on code.google.com by juli1.bec
on 2014-12-30 17:44:28
Or flot or rickshaw etc
On 30 Dec 2014 17:44, <google-visualization-api-issues@googlecode.com>
wrote:
Original issue reported on code.google.com by ken.horn
on 2014-12-30 18:53:00
What is the status of this ?
@albertolobrano As far as I know, this is a Terms of Service issue more than a technical one. Google has requested that we download the library from their servers for use. I follow some of the other support channels for this API and I haven't seen any indication that this is likely to change, though I don't work for Google so I wouldn't have inside knowledge.
I am building an application with polymer and firebase which they support offline mode and i was hoping the charts could do the same. Let's see if someone from google will notice this thread and come back with more information.
+1 offline use is a must.
I am in favor of offline use of this API
Please google. The request of offline is very important for us
+1
Detracts from the user experience in apps hosted in local networks that demand authentication for internet access.
I Download bellow links:
https://www.google.com/jsapi https://www.google.com/uds/?file=visualization&v=1&packages=corechart https://www.google.com/uds/api/visualization/1.0/cc4e780f27c723c0cb35ec1e38ec2bb9/ui+en.css https://www.google.com/uds/api/visualization/1.0/cc4e780f27c723c0cb35ec1e38ec2bb9/format+en,default+en,ui+en,corechart+en.I.js https://ajax.googleapis.com/ajax/static/modules/gviz/1.0/core/tooltip.css
and use them in google charts:
<script type="text/javascript" src="jsapi"></script>
<script src="corechart" type="text/javascript"></script>
<link href="uien.css" type="text/css" rel="stylesheet">
<script src="format.js" type="text/javascript"></script>
<link type="text/css" rel="stylesheet" href="tooltip.css">
Please up the priority for this, Google Charts is brilliant but this is a major showstopper.
https://developers.google.com/chart/interactive/faq unfortunately states:
Can I use charts offline? Your users' computers must have access to https://www.google.com/jsapi in order to use the interactive features of Google Charts. This is because the visualization libraries that your page requires are loaded dynamically before you use them. The code for loading the appropriate library is part of the included jsapi script, and is called when you invoke the google.load() method. Our terms of service do not allow you to download the google.load or google.visualization code to use offline.
I have been using Google Charts to provide visualisations for a household electrical control system. This restriction means that the users won't be able to see their system if the internet connection goes down. At the least it would be good if it was OK to maintain a long-lived cache that could be preemptively updated so that (for example) one or two accesses per month were sufficient.
Please at least tell us if there is a possibility for offline use in the future. Based on this we can make an informed decision about using this library or not.
Later edit: Just in case anybody might be interested, I found that D3 charts libray suited my needs better and allows offline use. It also has a GWT wrapper (which was one of my requirements).
@mihajul This issue has actually never received a reply from a Google staffer, which probably says a lot. I've seen comments in the mailing list that they would like to provide this, but under the current Terms of Service, it is prohibited. So, if you need to make a decision, assume the status quo will continue.
Further evidence is that the team continues to put effort into the loader mechanism, rather than providing a static versioned endpoint, which would be preferable for offline use.
It was necessary to work on the loader in the recent past because the previous way of serving the code was being deprecated. The new loader also provided a way we could offer frozen versions, rather than always forcing updates upon all users.
We are understandably reluctant to make long term commitments to provide something that is not yet available, whereas it is much easier to make a long term promise about something that is already available.
Allowing offline use is a technical possibility, though we will have to investigate the legal and security issues. By continuing to serve the API, we also have the ability to change it as necessary, even the frozen versions.
We have discussed the possibility of open sourcing the Google Charts code, and I am pretty sure that has been mentioned in years past. But making it happen is itself a large project, and weighed against all the other priorities, it tends to fall off the table. With every decision we make about how the code is structured and maintained, we try to move closer to eventually open sourcing it, but it is still a long road ahead.
On Sun, Jun 25, 2017 at 10:52 AM, Nicholas Bering notifications@github.com wrote:
@mihajul https://github.com/mihajul This issue has actually never received a reply from a Google staffer, which probably says a lot. I've seen comments in the mailing list that they would like to provide this, but under the current Terms of Service, it is prohibited. So, if you need to make a decision, assume the status quo will continue.
Further evidence is that the team continues to put effort into the loader mechanism, rather than providing a static versioned endpoint, which would be preferable for offline use.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/google-visualization-issues/issues/277#issuecomment-310907100, or mute the thread https://github.com/notifications/unsubscribe-auth/AAizDW5kBaAso-lwH3lUg0GoviiuI_q2ks5sHnQqgaJpZM4Gdn_c .
-- Daniel LaLiberte https://plus.google.com/100631381223468223275?prsrc=2 dlaliberte@Google.com dlaliberte@google.com 5CC, Cambridge MA
+1
The dynamic loading is also a problem for use in Chrome / Firefox / Safari extensions. It's not that you can't access the dynamically loaded code, it's that reviewers are rejecting extensions that load and execute code from an external source. I just had my extension pulled from the Mozilla site because of this (and also the use of eval in Google's code).
Original issue reported on code.google.com by
suls%suls.org@gtempaccount.com
on 2010-05-11 10:42:04