At 11:54 AM 5/27/2000 -0700, you wrote: >Hi folks: > >With that said, I would be interested to learn more about the existing GUI >client. What are the group's specifications for the UI in terms of core >functionality, features, extensibility? Who is currently in charge of >defining/implementing it? The GUI class mentioned, is it just a quick hack >to insert and retrieve files? (is it really just one class?) How about >locating files on the network? I sense that you guys don't want to commit to >Swing - have you considered maybe a Web interface? Questions, questions... >
Actually, I'll admit that I've hung around a couples weeks and offered suggestions "here" without first asking these questions - I have no idea if anyone is in charge of developing the GUI. If I've been rude, I apologized. Still, I'll repeat the ideas I've submitted - now connected to a real, existing application. I don't know if anyone has look at the UI I recently submitted but I would like to think it is a bit more than a quick hack. While currently it mostly appears as merely a relatively web-bbs view, it is altogether a sophisticated and extensible interface. The client has it's own interactivity language that can be used to specify how a series of documents are put together into a view. And it lets see stuff other folks posts to freenet automatically. Now since freenet is a text-retrieval engine, making it "look like the web" is fairly trivia - all you need is a web server run at the client machine with perhaps a little filtering. (but we need to agree on what the exact protocol of a freenet URL would be - sure "freenet://Key" but what's the terminator of the key?) Indeed, a local web server makes more sense to me than a mozilla plug-gin since the user wouldn't have to install a large application. Imagine if freenet eventually had a "one floppy" set-up size. "Any web brousser" seems like the ideal target for most of the document that will be one free - these will be broussed, played or saved and all the existing apps will do that just fine. The trick is to allow enough interactivity so that when someone posts a document or composes a "freenet page", they can also post a link to that page on freenet itself and have people see the existence of the new page. The client I mentioned allows someone to do that. And it is working now (though most of my testing has been simulation - I have posted and viewed). This existing client can be extended to achieve most of the other aspects of the classic CGI applications (a hits counter would be a bit wasteful)and beyond to the classic "Xanadu" type features - two way links, all pages annotatable and so-forth. Basically, if a semi-programmable application is the viewer, the dynamism of most interactive web pages can be added by simply adding a program as your basic document. Updatability of documents can be done this way as well (keyVer1, keyVer2...or KeyTimeStamp345543step345) Now, the one reason that I'd like folks to notice this is that the system will only work if a single interactivity language/client system becomes standard. Of course, single freenet documents are either static or expire in a fairly uncontrollable fashion. The views or "compound documents" that any client would use to provide updates on new documents would be composed using agreed ranges of values such as Key1, Key2 etc. (Though my client uses a similar but more complex system which allows an extensible tree structure. Keep in mind that this is a system I have worked on - full time - for about six months - though most of the time not knowing anything about freenet. I think of it as having fairly rich functionality). So, if folks are going to be creating "compound" documents by adding documents having related keys (key1, key2...keyN+1), there would have to be a universal "protocol," a language, which describes how these things are found and viewed. Considering we HAVE one such language, I would suggest that it would be good to standardize on it because without such a language, people wouldn't be able to create "compound documents" and thus all link updates to freenet would have to come from the outside - which is a definite VULNERABILITY and we don't like vulnerabilities. The only OTHER thing besides making an existing language standard that would make sense to me would be to wait until something more standard like XSLT can accomplish similar things. But this may be a while. And the point is to have a single updatable viewer. Then the language can be updated over time - look at the evolution of HTML. OK, I released the code yesterday, so maybe I'm being touchy. But I really hope to get some feedback about it. (PS, it's at /www.crucialquestions.com/ccq_fnv.zip and it's open source, of course, submit for your consideration) Joe _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
