On Friday 12 February 2010 00:50:30 Ian Clarke wrote: > > Firstly, all I've done is made a proposal, and defended that proposal, I'm > not dictating anything to anyone. > > The reality however is that FProxy is a mess. We've basically implemented > our own web framework, and it violates almost every rule of good web > framework design. We've got HTML structures implemented in Java code, and > no convenient support for AJAX, among other flaws.
This was not explained in your prior email. And I disagree. HTML is supposed to be used for structure, there is nothing wrong with structure in code. Presentation should not be in the code, and neither should english strings, but they are not (okay, 99% of the time they are not). Yes it would be possible to express structure with a different language, say XML, but there would be no benefit, the outcome would be exactly the same, and the way we do it now we get compatibility with old/non-js/accessible browsers for free. We then convert structure to presentation using CSS (which can do *almost* anything, including drop-downs and menus), and we use Javascript for live data updating and occasionally for update-in-place interactive stuff. You may accuse this of being a 1999 model, but it's a perfectly good model. The web-pushing branch provides convenient support for AJAX, specifically for live updating of on-screen elements. This has been implemented for many parts of the node: - The progress bar when loading a page. - Individual progress graphics and an overall summary message when loading a page with lots of inline images. - The downloads page. - The statistics page. - The connections pages. - The set of alerts shown on various pages. - The status line shown on every page. Some of this is a little clumsy visually (sashee isn't a designer), but accessing it from Java code is easy enough. > > If you disagree with this observation then say so, and let's debate it. I do. > > But if you accept that FProxy has serious and fundamental flaws, then it > makes perfect sense to replace it with a pre-existing open source web > framework that has elegantly solved all of these problems. GWT is the best > candidate for this I've found. I don't accept that, but I *do* support using GWT. GWT is a good means to generate cross platform Javascript code. > > I know a lot of work has gone into FProxy, but that fact alone cannot > prevent us from considering the pros and cons of replacing it. We've thrown > out a lot of code over the years with Freenet, its an essential part of > software development. I agree, but I have not seen any credible reason to throw out fproxy just yet. > > Regardless, nothing will get thrown out any time soon, we'll be lucky if we > get a new UI for Freenet 0.9. So you've given up on deploying a half-baked UI in parallel to the main UI in a shipped release? If so that is progress... > > All I've done is proposed that we improve our UI, made an argument for why > doing this properly requires replacing fproxy's current infrastructure, and > argued that GWT is the best candidate for a replacement web framework. > > The reality is that FProxy is a mess, we've basically implemented our own > web framework, and its not a good one. We have HTML constructs embedded > directly in code, which is always a bad idea. > > Sooner or later our web interface needs a reboot to address these > architectural deficiencies, and I don't think there is any advantage to > pretending that this isn't the case. I disagree. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20100213/eec7748d/attachment.pgp>
