Comment 1 by jteh on 2013-01-11 22:26
In principle, I think this is a good idea. We've discussed this before, but have never had time to work on it.

My major concerns are technical ones:

• Some add-ons are huge, so there would be download time, server disk space and bandwidth considerations. Certainly, we don't have the bandwidth or disk space to host something like this.
• Would all add-ons be considered or only those in some sort of official repository? Note that there is no official repository yet.
• If all add-ons, when would they be uploaded? We'd also need to prevent disk space abuse.
• We'd want to come up with some way of eliminating duplicate add-on files to minimise server disk space consumption.
• Storing monthly donation status would require some sort of automated link to !PayPal. This is certainly possible, but not trivial.

Comment 2 by Q (in reply to comment 1) on 2013-01-11 22:34
Replying to jteh:

In principle, I think this is a good idea. We've discussed this before, but have never had time to work on it.

My major concerns are technical ones:

• Some add-ons are huge, so there would be download time, server disk space and bandwidth considerations. Certainly, we don't have the bandwidth or disk space to host something like this.

Two ways we can approach this. Either maximum add-on size (probably a good idea for things like voices and whatnot) and what I had already intended, the downloaded profile or whatever it's called isn't applied until everything comes down. Yeah it may take some time for your initial linkup, but you do get an eventually-consistent profile.

• Would all add-ons be considered or only those in some sort of official repository? Note that there is no official repository yet.

We could give each user 20 mb? or whatever, an arbitrary amount for them to use for add-ons. This is a solvable problem, we could even leave add-ons out of an initial implementation and if the desire is there iterate on that feature.

• If all add-ons, when would they be uploaded? We'd also need to prevent disk space abuse.

I thought NVDA would upload them in the background. It would go like this:
When a new add-on is installed into NVDA, NVDA hashes this add-on, sends the hash to the webservice asking, do you already have this? If not it's sent. This also dramatically limits disk space if add-ons are stored by hash.

• We'd want to come up with some way of eliminating duplicate add-on files to minimise server disk space consumption.

See above.

• Storing monthly donation status would require some sort of automated link to !PayPal. This is certainly possible, but not trivial.

On the other hand, I'll donate my already-written Paypal IPN module which I use to power q-continuum.net's ecommerce system, which brings it from nontrivial to already done!

Comment 3 by jteh (in reply to comment 2) on 2013-01-11 22:43
This all makes sense. Server disk space/bandwidth is still a concern, though. Even 20 mb per user is something we can't currently manage without additional financial cost, especially with multiple downloads per user.

Thanks for your willingness to donate your !PayPal IPN module. I started work on one of those a while ago, but never got around to doing much with it. :)

Comment 4 by ragb on 2013-01-11 23:03
Hi,

In principle I like this idea very much.

Some points:

• If NV Access (or any entity) is to provide the disk space, I only see it viable if the user pays for it. At least for huge space. Say for instance free account gives 20mb, and payed gives 200mb, 1gb, or anything. S3 or something like that could be used to host files. This way the disk and bandwidth costs are more or less mitigated. Of course doners could be rewarded with space too, depending on the amount or something. However I have some concerns with this idea, that is, any add-on beeing stored with no quality control or anything. It's almost a dropbox-like service.
• My idea for this would be to base it on the idea of add-ons repositories. That is, the sync system would simply check repositories for add-ons and install it from there. I believe we can have an oficial repo of course, but have the possibility of additional repos (for comercial add-ons for instance). This means the repository stuff blocks the cloud system. (we are discussing repositories for some time, maybe this is a chance).
• We have the problem of synking configuration. NVDA state is in the config, dictionaries, some add-ons have its own config files (damn me!) and so on.

I find this a good idea, but don't see it as trivial as it may seem to implement, either on the cloud-side (whatever cloud means these days) and NVDA "client" part.

Regards,

Rui Batista

Comment 5 by Q (in reply to comment 3) on 2013-01-11 23:07
Replying to jteh:

This all makes sense. Server disk space/bandwidth is still a concern, though. Even 20 mb per user is something we can't currently manage without additional financial cost, especially with multiple downloads per user.

What the heck are you guys doing? ? I pay $9.00 per month for a VPS which gives me 25 GB of disk space, and 1 TB of transfer. That would allow 1000 accounts, assuming 20 megs per account, and let everyone download 50 times. This price scales linearly. If you have dramatically more, I.E. 100,000 accounts, Dreamhost will give you 3.8 Tb of disk space on a vps for $22.95 a month. It's certainly not free, but it's anything but restrictive.

Thanks for your willingness to donate your !PayPal IPN module. I started work on one of those a while ago, but never got around to doing much with it. :)

Here you go, PayPal IPN:
http://hg.q-continuum.net/paypal_IPN
Simply instantiate a copy of paypal_IPN.listener.PayPalIPNListener, its only optional parameter is sandbox, which defaults to False. Then, use the process_request method on the URL which PayPal sends in its IPN request.

Now what? It sounds like we've come to agreement that this is a generally good idea. We need to spec it out and decide who wants to work on it when. As I've already said I'm willing to do the web work with Flask, which is a very simple Python web framework which I am familiar with. http://flask.pocoo.org

==Preliminary thoughts on an API==
POST /create_account
GET /account
{'username': 'bob_smith', 'last_donated': blah, 'addons': 'OCR', 'hash': blah}}

POST /addons #for uploading
GET /addons/ #to retrieve a particular one

Comment 6 by jteh (in reply to comment 5) on 2013-01-12 10:48
Replying to Q:

What the heck are you guys doing? ? I pay $9.00 per month for a VPS which gives me 25 GB of disk space, and 1 TB of transfer. That would allow 1000 accounts, assuming 20 megs per account, and let everyone download 50 times.

We're on a Linode 512, which gives us 200 gb transfer. It looks like that's gone up; it used to be less. What you get is far better value, but we've been bitten by cheaper VPS hosts in the past. They aren't created equal, and with the high traffic and load our server experiences, we were finding performance to be a major problem. Also, we used Dreamhost in the past for shared hosting and while that's not VPS, suffice to say that we were pretty unimpressed with their service overall.

My feeling (and I'd need to discuss this with others) is that while this is a great idea, given other priorities, I'm not willing to devote specific funding or a huge amount of my development time to this. (It's worth noting that as this grows, it will very probably require more funding.) However, if it can be done without those, I'm happy to see it happen and help where I can.

Comment 8 by zahari_bgr on 2014-04-11 01:40
Hi,
I think that one will be very useful for many people, who work on multiple computers, and also when reainstalling the operating system.
It could be a special feature for those who have donated in last 12 months at least some amount defined by NVAccess.
Also, it could be used as a reward for other contributers who have provided a patch, developed an addon, made new translation or maintained an existing one, top 10 of people who have reported bugs etc., again for 12 months back.
The amount of disk space may differ depending of contribution.
I think the bandwidth wont be an issue if there are multiple mirrors, e.g. 1 mirror per continent hosted in the country with highest amount of users, and expanding when there is a need. If you have bandwidth issues that is a good solution anyway. And there are low cost vps everywhere.

Also, it could help NVAccess to maintain a even stronger userbase.
Later, those accounts could be used in other places like the wiki, the issue tracker etc. with implementing a oauth mechanisum.
And there could be other services in the future, e.g. live support.
I think it will be great and it should start from somewhere... someday.

@jcsteh What is NV Access's current VPS hosting plan? In case this has improved since #2926 (comment), we may want to reconsider this ticket.

This is something we might consider in future, but our thinking is that it would be part of a low cost monthly subscription of some sort which would also include other services (yet to be determined). This would allow us to ensure we can scale with future demand and also create a small revenue stream.