On Thu, Dec 19, 2002 at 02:20:35PM -0800, Ian Clarke wrote: > > > Oh? What was wrong with Simon's proposal? I see no reason that we > > > couldn't do that. > > Redundancy, for starters. > > I explained in a previous email how this can be achieved elegantly, and > without two progress bars. What is wrong with my proposal? > > > Without using javascript? Remember, we advise users to disable > > javascript in their web browsers if they can, because something may > > always get through the filter. > > If they did, then it will appear in a browser window as normal - larger > than we intended, but it will work just fine. Personally, I doubt even > 5% of our users follow our advice with Javascript anyway - and > Javascript is one of the easier things to filter for, since there is a > finite number of ways to embed Javascript in a HTML document. If we used an only-pass-it-along-if-it-parses filter I would be happier about it... without such a monster, we have to filter out anything that any buggy browser implementing a beta version of a standard anywhere might misinterpret. It's an intractable problem at worst, a maintenance nightmare at best. Even with such a parser, I'd still be concerned about new ways to get around it. > > > > Not really, it is possible to make most graphical representations look > > > ok in text if you are smart about it - but I don't think you can ever do > > > that with frames. > > Or tables. Or anything. > > Bullshit, it is relatively easy to make a website, whether it uses > tables or not, to look ok in lynx or links - hell, you don't even need > to look further than our own project website if you don't believe me. > > > lynx... [GOT ][GOT ][NOTGOT][NOTGOT][NOTGOT]... is the best we can > > hope to achieve without browser specific code (yuck). > > If it is done using tables and cell background images, then a lynx user > won't even see the progress bar. All they really need to see is the % > complete. > > > Simon's proposal is not a solution, it is a half-baked idea. > > You keep saying that - but I haven't seen a shread of support. WHAT IS > WRONG WITH SIMON'S IDEA? It does not address the issue of redundancy. > > > But we would end up with > > two bars, organized the same way Bombe's cellular system works. In other > > words, we have a plain progress bar, which fills from one end and > > represents the total blocks downloaded, and we have a color coded strip > > that represents all available blocks (as slices) - one color for > > fetching, one color for failed permanently, one color for failed but going > > to retry, and one color for not tried yet. > > It isn't necessary to have two progress bars. All we need is an arrow > or some indicator on the single progress bar indicating where the > download will be complete - but which moves to the right one block every > time a block download fails. What about retries? You'll have to move blocks that need to be retried to the right hand extreme, so why not go with the scheme I suggested in the other mail (involving a fixed box, and successes are one contiguous block filled from the left, and permanent failures are filled from the right). :) > > > > I ment a browser window with no tool-bar, not completely borderless. > > The question stands. > > It will use JavaScript, but will fail gracefully if it isn't present. Ugh. Blech. Gerbleghl. > > Ian. > > -- > Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] > Latest Project http://cematics.com/kanzi > Personal Homepage http://locut.us/
-- Matthew Toseland toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021220/198181c1/attachment.pgp>
