On Tuesday 25 Jun 2013 22:23:13 leuchtkaefer wrote: > > > > > FredPluginHTTP is only for trivial toadlets that only produce small amounts > > of > > HTML. You should probably be using toadlets. There are several plugins that > > use > > this, e.g. KeyUtils, Library, etc... > > > > What exactly is your plugin supposed to be doing? Even if it's only editing > > the index, it could be generating large HTML pages, so returning the page > > as a > > String may not be best. > > My plugin is very basic yet but a good point for start interacting with > freenet and tests. > It creates one new menu and one page (the name of the menus are buggy, need > to fix). > It implements FredPlugin, FredPluginL10n, FredPluginBaseL10n. I read > somewhere that FredPluginHTTP is not useful so I am not using it. I am using > toadlets. > What I did is to reuse some classes from WebOfTrust. I used: WebInterface, > WebInterfaceToadlet, the interface WebPage and WebPageImpl
Okay, yes, that's the right thing to do. Ideally we'd like a HelloWorld plugin that uses toadlets, as an example. > > > Re documentation, please let me know if you have specific APIs that you > > don't understand, and I will document them. Documenting *EVERYTHING* would > > probably take all summer and I don't have time. > >> > If you can document some classes it would be great. I will ask when I need it. > > >> Not yet sure if my contribution on file sharing will be coded in a > > completely independent plugin or for instance inside the WoT. Currently I > > think > > is preferable to write an independent plugin for file sharing. Besides, > > developing a clean and better documented plugin is helpful for the > > community. > > Moreover, it helps me to understand better the functionality of freenet and > > some > > plugins while providing me of an space to test things with the abstraction > > of > > weird behaviors from other complex plugins. > > > > Not WoT; WoT has nothing to do with searching. You should interface to WoT > > using > > FCP. Library currently does searching, so there is a question of whether > > you > > want to implement the searching part within Library. > > Of course not. It is clear that WoT doesn't do searching. The thing is > that share is based on an identity basis or at least it is what I thought at > the beginning. > And I am not sure how to connect the searching with the index per identity. > Is it the root of the > index in Library a key to a specific identity? Hmmm. Yes, the indexes will be linked to a specific identity. So what exactly you search will depend on which identity is logged in at the moment. > ============================================================================= > >> C) Questions/Need clarifications: > >> > > We do not share ANYTHING from the datastore. You are still mixing up > > different > > levels / layers. The datastore is just a cache, and the files we upload are > > not > > usually stored in our own datastore; they are stored in other people's > > datastores. They are chopped up into lots of pieces which end up on > > different > > nodes. > > I have some understanding of the underneath layers. But I though that it was > ok to share datastored items with our darknet peers. Possibly with our darknet peers. But our published indexes will be shared much more widely, across the Web of Trust (which has nothing to do with our darknet "friends"). > Regarding sharing, I was thinking in 3 different approaches: > a. For documents: it is explained better with an example. Sometimes I > download a file, store it. Maybe some days later someone mentions sth related > to the file and I want to share it. It requires access to the cache datastore > or to the download list (chk of the downloaded file?). That explains why I > was thinking in having access to datastore. Leave it on the downloads page and click a button to add it to your index? We already have the ability to recommend the file to our friends, provided it's still on the downloads page. (Although this just sends the URL, not the file itself IIRC). > b. For webpages: normal social sharing, the typical share button. It works > immediately after reading or sometimes after accessing the preview/thumbnail. > But that method requires sth from the document' publisher. It needs the > publisher adds the sharing button. Yes. We can share it with our darknet friends, or we can include it in our *anonymous* filesharing index. Both are useful, but they are different: Sharing it with our friends is not anonymous. Including it in our anonymous (pseudonymous) filesharing index *is* anonymous (pseudonymous), and visible to anyone who can see us, rather than only to our direct friends. Also it doesn't depend on us being online at the time. The difference between sharing with our traceable friends and sharing with our wider untraceable connections is a key one in Freenet and we need the user interface to reflect it, but still be "easy" or "obvious". Possibly a Share button could provide the option to do both. > c. For webpages: some functionality like scoop.it! It does not depends on the > publisher. Each identity can be use to "curate" content. For easy use, it > requires to add chrome or firefox extensions to add a button on the > navigation toolbar. Yes, exactly, we would be curating the indexes. Maintaining actual freesites is something else. > > > What we want to share is a list of files, which the user has manually added > > to > > their filesharing list. In the index, the files will be just a URL > > (CHK@blah,blah,blah/mybigfile.zip), with some metadata (size, type etc). We > > can > > get these files from several places: > > - Files we have uploaded. When we upload a file, we want the option to > > automatically add it to our filesharing index when the upload finishes. > > - Files we have downloaded. Ideally we'd like to be able to add files from > > our Downloads page. This involves the client layer; when you are ready to > > look > > at this let me know, it's a bit complicated but I can point you to code > > that > > should make it not too difficult (especially the code that renders the page > > now). The list of files we've downloaded, on the Downloads page, is *not > > part of the datastore*: It's a separate system. > > - Files we have just added by URL; we may have found it anywhere, it > > doesn't > > matter, we can add it manually. > > - Files from other indexes. > > This description is very useful. Good. > > >> 7) Already mentioned before, is it better to have an independent plugin > >> for > > file sharing? What do you think? I prefer do it independently. > > > > Yes, IMHO it should probably be independant. The main jobs are: > > - Maintain your own index. > > - Search other people's indexes. > > The first overlaps with WoT, the second with Library. Both functionalities > are a big thing not sure if I can do both during one summer. I am not able to > estimate work at the moment. Okay, although searching is already pretty much implemented by Library so it should be possible to adapt it. I'm not asking for a fully optimised implementation here! I'd hope to have a working system though - which means we need both tools. But don't worry about it; if the task is larger than we originally estimated, we can take that into account, and still pass you. > > > The second overlaps with Library, but the first should probably be > > independant. > > So it probably makes sense to have a single plugin for both jobs, or maybe > > combine it with Library. > > I prefer one separate plugin. Otherwise, it is very messy. Meaning we have separate tools to search for files versus for pages?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
