On Thursday 15 Mar 2012 21:02:26 Ximin Luo wrote: > (Top-posting because previous post is too long to reply to in-line.) > > ## refactoring > > Refactoring the code helps to make it more understandable for other coders. > One > of the reasons why I don't work more on freenet myself is because it's > extremely difficult to make any changes that are more than a simple bug fix.
Hmmm, good point. But from FPI point of view, unless it's a very quick and high impact refactoring, it's probably too long term. > > When I was writing code for the config subsystem to separate out different > files into different directories, this was very frustrating and took up much > more time than I expected. I'm still curious as to why. > > NB: I'm not implying you should be doing all the work toad, please don't think > this. And please don't think that my opinions are automatically invalid / less > worthy just because I haven't committed code for ages. I just want to express > my view of What I Would Do If I Were God. Okay. :) I don't mean to criticise un-constructively, just have a useful conversation. > > People can do what they want but it doesn't mean it's a good idea. Granted, I > consider "code quality" independently of any issues such as funding, but > focusing too much on the latter leads to bad software. If there's pressure > like > this, ignore it, find something else in the meantime until it goes away. I plan to continue working for FPI for the time being. Partly because it's part time and fits conveniently with studying. Partly because getting a programming job in the UK requires a degree even if you have some rather odd experience. > > ## freenet Events API > > freenet does not provide a great API for running callbacks and scheduled > tasks. I'm not sure what you mean here. For example, the client layer has unique requirements. We simply can't just change it to use java.util.concurrent. Database jobs must run on the database thread, and no other thread may have access to the database, because the client layer is not designed to deal with simultaneous transactions. This avoids performance problems (separate caches for each client; simultaneous disk I/O), and complexity (refreshing everything constantly, which requires a more query-oriented architecture; we'd have to change pretty much everything, and it'd probably be slower). But it's messy, in particular it requires passing around ObjectContainer's. > Converting everything to use java.util.concurrent and/or > com.google.common.util.concurrent would help this a lot. Of course, Library > can > and currently does implement this itself, but it's fairly sloppy, and other > plugins would benefit if such a framework were provided. If you simply mean replacing Ticker and Executor, that's fine by me. > > Some common tasks that plugins would like to do, which really should be > provided by the underlying application: > - run tasks in the background > - run tasks according to a particular schedule > - cancel running tasks How do you propose to cancel a task once it's started? I guess it depends what sort of task it is. If it has a boolean and periodically checks it then fine; this would require a subclass ... > - handle dependencies between tasks, so that e.g. if A depends on B and I > cancel B, A is automatically cancelled. That's a nice bit of functionality yeah. Nothing in fred needs it at present, although radical refactorings might make it more useful. > - group tasks into related categories so one group doesn't affect the other. > (e.g. tasks for the group "Library/b-tree-write/index-<URL>" won't starve the > resources of group "WoT/background-trust-calculation") If you are scheduling tasks in a limited pool this makes sense. Freenet generally doesn't do this because most tasks are either CPU intensive and complete quickly, or are blocking / I/O intensive and take ages but don't use much resources. Also many tasks are latency sensitive. And on modern JVMs, lots of threads are cheap, although memory is an issue, we do need to keep it down if possible ... > > ## Library algorithm > > You keep talking about specific things like "only fetching a single block in > the common case". Nobody else knows what this means, even I don't (off the top > of my head) because I haven't looked at the code in several years. I quoted a bug explaining this. > > On 15/03/12 13:03, Matthew Toseland wrote: > > > > https://bugs.freenetproject.org/view.php?id=4066 > > And categories: > > library > > b-tree-index > > Back to your mail: > > Having a proper specification that separates different concerns out into > layers > (e.g. logical structure; on-freenet structure; data format; network > performance) helps greatly to make the algorithm understandable to other > people, and yourself if you don't work on it for ages. > > If, instead of saying "only fetch a single block" you say "the on-freenet > structure format has persistence issues, and here's a potential solution", > it's > easier for other people to understand what you mean. "only fetching a single block in the common case" is a specific mechanism (relying on significant format changes) for achieving the goal "radical performance optimisation for the average case for library searches". And I have explained it on the bug I quoted. However I agree documentation is a good idea especially in Library. I agree that layering is good. The disagreement comes when the layering is impeding major performance optimisations - then it needs to be altered. > > ## config management > > Code for read/writing the config in embedded inside the classes they control, > which clutters up the code and makes it confusing. Config code should be > separated from the actual application. It would also be nice if this was > exposed to plugins. Separated how exactly? You want to call getters via reflection, like java beans? It is always going to be the case that changing some settings on the fly will be somewhat involved and require methods for it; the classes are only one way to write such an interface, I'm open to other mechanisms given that config happens very infrequently. > > Being a daemon is why the current config system is NOT SUFFICIENT. I need to > be > able to lock certain config settings, such as where to keep the datastore / > run-time files themselves, to conform to the FHS. It's best that such settings > are kept in a separate read-only file. The current system only reads one file, > freenet.ini. Sounds to me like that could be achieved with some fairly small changes; I still don't see what the problem is. > > Updating its own binaries is not a problem if freenet knows where the binaries > are. The current installer puts them in a rigid place, however this is > incompatible with FHS. A rigid place? I don't follow. If you are doing FHS you are using a package; the installer is never going to comply with FHS as, apart from anything else, it shouldn't be run as root! Updating its own binaries is incompatible with the standard unix way of doing things, isn't it? Even if it's not technically a violation of FHS? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20120316/ea6c2b19/attachment.pgp>
