2010/9/18 Cl?ment Vollet <cvollet at gmail.com>: > Well, a (good?) reason could be for those using text-browsers (on remote > access, it is probably faster).
I don't really consider that a good reason. How many tens-of-thousands of users are we willing to lose in order to keep the 8 people who for some weird reason insist on using lynx? > But, I thought that we agreed last time that > we were going to keep FProxy as a UI for those who don't want to use > javascript, and build a new one for those who don't care. The overhead > shouldn't be too consequent, especially if we introduce a template system for > FProxy. > > This way, we satisfy both needs, and we can keep FProxy for operations not > being supported by the new UI (it may take some time before we achieve feature > parity with FProxy). > > Does this seem reasonable? Yes, I'm in favor of keeping fproxy for developers and other people with "niche" requirements, those people can continue to work on fproxy per their needs. But the majority of the project's UI efforts must be on making Freenet easy and pleasant to use for the majority of users, rather than pandering to lynx users and those that are morally opposed to Javascript for some reason. Ian. -- Ian Clarke CEO, SenseArray Email: ian at sensearray.com Ph: +1 512 422 3588
