I guess I should stop sulking given we're going to be talking about this at the meeting. :)
On Saturday 18 September 2010 18:45:30 Ian Clarke wrote: > 2010/9/18 Clément Vollet <[email protected]>: > > Ok, then, should I proceed like that : > > > > - adding a templating system, > > - design a new UI, and implement it in HTML + CSS only, > > - add GWT support (well, use it if it's already implemented) to make it more > > dynamic. > > If we are going to use GWT we should really be using it for the entire > UI, but not for the "proxy" component of fproxy, which displays pages > retrieved from Freenet. Based on my understanding of GWT it is > designed for creating UIs in a browser, which is what we need, but it > is not designed to degrade gracefully if Javascript isn't supported. We already use it for the "proxy" component, and we use it in a low level manner, specifically to modify existing tags, so that fproxy works without javascript but works better with javascript. In particular, web-pushing can solve the browser connections limit problem that has plagued Freenet since we first added fproxy. So it is clear that GWT can operate in both modes. Widgets and the designer tools presumably don't support a pure HTML fallback. > > I find the whole argument that we must support people who don't want > to enable javascript to be unpersuasive. We can and do filter out any > javascript from any page retrieved from Freenet so that isn't the > issue. We are talking about people refusing to run Javascript that is > written by us and served up by the Freenet node to their browser. It > is no more dangerous for someone to run Javascript written by us in > their browser, than it is for them to run Java code written by us in > their operating system. > > Given that disabling Javascript with Freenet does nothing to improve a > user's security, can someone remind me why our entire approach to a UI > redesign is predicated on supporting those that irrationally insist on > disabling Javascript in their browsers? Why must we inconvenience 99% > of our users to accomodate the irrational 1%? Okay, since you asked, the main cases I can see where you'd want to turn off javascript: 1. Users with low end computers. People in hostile regimes will often have low end computers. 2. Users who turn off javascript as a matter of course. Most privacy threats and remote compromises in browsers use javascript. E.g. the EFF's browser profiling project gets most of its information via javascript. We can't even berate the user for not using a separate browser now, because they will likely be using their standard browser in privacy/incommunicado mode. 3. Hardcore privacy geeks who use ssh -X (Google Docs is really slow with this, web-pushing has performance issues too; the app still has access to the clipboard but I imagine SELinux X sandboxing has the same issues). 4. Some blind users still use lynx/links. On Saturday 18 September 2010 20:23:55 Clément Vollet wrote: > Well, a (good?) reason could be for those using text-browsers (on remote > access, it is probably faster). 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). IMHO this is not a good idea, if we have two UIs one of them will decay. Another point is that we need theming support, which might as well be in CSS. Anything that can be styled with CSS is presumably HTML? I guess GWT can be themed in CSS anyway, it must be generating HTML at some point.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://freenetproject.org/cgi-bin/mailman/listinfo/devl
