On Saturday 26 October 2002 17:00, you wrote: > From my point of view, the plan was to separate the insert functionality > into a separate servlet to make it much easier to expand the various > services offered by fproxy. There's not that much code shared between the > two servlets (apart from some of the bug-fixing inner-classes) so it seemed > sensible to separate them. > > This should allow a much more enhanced insertion functionality via fproxy. > One idea I had would be for NIM-style inserts to automatically search for a > free slot after the last-known used one specified by the author. > > Hope I'm not stepping on any toes, You're not. Glad to have you aboard. I just phreaked out a little because I saw large changes to code I have been working on by someone I didn't know. I haven't been hanging out on #freenet much anymore.
>I had a look at fproxy and wondered if > it would be possible to give any more useful information to users when > downloading a freesite (e.g. Restarts, when a redirect is processed, etc.). > Matthew Toseland suggested seperating the insert and request functionality > to make things much clearer would be a good place to start. I'm currently > trying to get HTML splitfiles anonymity checked (a little more complicated > than I first thought). > > Back to the useful information to users for freesite requests, it looks > like a Status servlet showing currently running page downloads would be a > good idea. The trouble is, how to you make this work on a multi-user system? i.e. I don't want anyone on the system to be able to see that I am eagerly awaiting the completion of the latest BoobieTown image. > > Other things that came up on IRC and/or in my head which might be useful > (though not necessarily always feasible!): > > More intelligent RNF, etc. failures for images (though we'd need someway to > know the browser was definitely processing something as an image, and if it > wasn't the right size it'd get squished/squashed/stretched) > > One solution to the problems of new users using the Key form on the fproxy > page for searches would be to check the prefix of the key, if its not CHK@, > SSK@ or KSK@ then bring up a suitable error/query page. Sounds like a good idea. It couldn't hurt to warn that people shouldn't be using KSK's either. Though I'm not really certain what the purpose of this field is. I think users could be just as well served by note explaining to paste freenet URIs after http://127.0.0.1:8888/. > > Would it make sense for fproxy to parse for external links and add > __CHECKED_HTTP__ to take the responsibility away from freesite authors > (though this might be too difficult to parse in all cases) This was discussed a lot. Like for months and months, when fproxy and the anonimity filter were first being written. The tenuous consensus was that it is too hard to do well. One error in the parser and someone can bypass the filter. Also, page authors expressed some apprehension that some intermediate application would muck with their html. > > Some kind of bookmarks system using data from freenet (either visited > freesites, or less likely to have privacy concerns, detect links on any > visited reesite - ie. it would pick up all the links on TFE the first time > its visited). Unless there's a way to store this securely, > > Automatic detection of newer edition (and maybe DBR) freesites. This has been on my list of things to do. I probably won't get to it soon. Go for it if you are interested. > > Web-based configuration of the node would be nice for mere users too :) Except that you are already half configured by the time you can see it. One other idea I had was a "canary in the coal mine" servlet that gives some sort of graphical boolean indication that the node is working well or that it isn't and should be restarted. We really don't know what the useful node uptime is. That might keep Windows newbies from running essentially zombie nodes. One note on the code. You probably already noticed that I rolled my own context managment for the splitfile insertion and retreival stuff using URL re-writing The reason I did that is because our javax.* implementation uses cookies for context management and I couldn't bring myself to write code that would force fproxy users to enable cookies. --gj > > Mat Burnham > > > -----Original Message----- > > From: devl-admin at freenetproject.org > > [mailto:devl-admin at freenetproject.org] On Behalf Of Oskar Sandberg > > Sent: 26 October 2002 11:52 > > To: devl at freenetproject.org > > Subject: Re: e: [freenet-dev] What's going on with fproxy? > > > > > > On Sat, Oct 26, 2002 at 01:12:25AM -0400, Michael Wiktowy wrote: <> > > > > > >New developer, aka Spark^ on #freenet. He asked for > > > > something to do > > > > > >so we told him to split fproxy insert out from fproxy. > > > > > > To what end? > > > I know there was some murmuring about getting rid of insert > > > > capability > > > > > from the gateway page (which was realized briefly). I would > > > > register a > > > > > very strong vote against that and prefer the opposite as a > > > > matter of > > > > > fact by including some DBR inserting facility. > > > > The old FproxyServlet class had just grown and grown and was > > on the verge of reaching critical mass and taking us all out > > in the bang. It was (and still is) desperately in need of > > some heavy refactoring to make it even moderately approachable. > > _______________________________________________ > devl mailing list > devl at freenetproject.org > http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
