On Thursday 22 Mar 2012 20:34:53 Ximin Luo wrote: > On 22/03/12 12:00, Matthew Toseland wrote: > > On Wednesday 21 Mar 2012 00:30:42 Ximin Luo wrote: > >> "Implicit dependency" means that changing some code in one area results in > >> a > >> logical error in the other, that is not immediately apparent in the > >> documentation nor any compile-time checking built into the language. > >> Obviously > >> this is not necessarily a bad thing, but there is a lot of it in the config > >> system, and elsewhere, including in how the configured values are used. > > > > Okay... > >> > >> For example, for the longest time there was no centralised management of > >> run-time files used by Freenet, and even now they are just a bunch of extra > >> fields in Node.java because I had no existing structure to fit such a > >> system > >> into. However, Node.java is such a fucking disorganised mess, with several > >> hundred fields, that it's not immediately obvious to everyone that they > >> should > >> be using "new File(Node.nodeDir(), fileName)" rather than "new > >> File(fileName)". > >> I cleaned it up when I first wrote that part, but it looks like misuses > >> have > >> slowly crept in again. > > > > So your complaint is that there is no single central point to put all the > > folder names in? Feel free to create one. > > > > Making stuff static is tempting but means we can't do multi-nodes-in-one-VM > > tests, although I believe classloader hacks can solve that? Is there much > > of a performance cost? Otherwise we can just use a global object and grab > > it from Node, or ClientContext. > >> > >> Yes, configs have EVERYTHING to do with "writing the values out". All the > >> read/write logic is wrapped up into a ConfigCallback (which throws a > >> InvalidConfigException) which is ONLY PASSED TO THE CONFIG SUBSYSTEM. Even > >> ignoring the obvious intention of whoever named these classes, the target > >> of > >> the read/write logic is completely detached from the logic itself. > > > > ConfigCallback doesn't do any writing out. And the getters don't throw. It > > can only throw when a value is changed. So it's still not clear what the > > problem is. > > Irrelevant. To repeat: > > - the target of the read/write logic[1] is completely detached from the logic > itself[2], and too strongly-coupled with the config system[3] > - too much implicit dependency, due to the way the variables are poorly > managed > > [1] whatever get/set acts on > [2] ConfigCallback > [3] via .register(), so only the config system sees it
There is some sort of sophisticated design elegance argument going on here that goes completely over my head, being a poor ignorant peasant. As I said we could change it to use getters and setters via reflection, but it would only be marginally cleaner. > > Who said anything about making stuff static? Stop making up random straw mans. > > "Feel free to create one" - stop making excuses for not cleaning up your shit > and telling someone else to do it when they complain! Node.java is a complete > fucking mess. To make any sort of progress in having a well-structured config > system, that needs to be cleaned out first. I'm very happy for other people to clean it up. However for FPI purposes, I will only do major refactoring if 1) I am convinced the cost/benefit is positive or 2) Ian tells me to. > > >> Your explanation about the ObjectContainer also assumes a severely stunted > >> events framework can't support fine grained thread control. Why can't > >> there, in > >> your imagination, exist SOMEWHERE, a framework that lets you mandate "only > >> run > >> jobs of type J in thread T"? > > > > And those jobs are called with parameters (ObjectContainer, ClientContext) > > ? Since we'll have to subclass it anyway, it's going to be more messy than > > the current solution, isn't it? Anyway DBJob/DBJobRunner is pretty simple > > (although it's hidden in NodeClientCore along with ClientContext > > initialisation which is kind of messy). > > This is bullshit, there is already a "DBJobWrapper implements Runnable" which > needs nothing extra passed in. In the general case, there are *always* ways to > get around fiddly crap like this, and they are much simpler than WRITING YOUR > OWN EVENTS FRAMEWORK (and logging framework and config framework etc etc etc). What events framework? Executor and Ticker? If you're not even talking about DB* then what classes are we arguing about here? > > > I agree we should make *Executor use the standard APIs though - while > > keeping the ability to change thread priorities. > >> > >> An events framework could handle errant plugins by setting a timeout for > >> all > >> blocking jobs. If they don't complete within X time, interrupt the thread > >> and/or kill it if it doesn't respond to the interrupt. If the plugin can't > >> handle it, tough shit their fault. (This is how certain companies run > >> reliable > >> services on a massive scale.) > > > > Can't be done. Period. > > > > It's Java. Java does not support killing threads. According to the > > documentation the reason for this is that killing a thread might cause > > synchronization problems. Which is true, but I would have thought it was > > solvable ... Anyway if you need to be able to kill stuff it has to run in > > *a separate JVM*. > > Then interrupt is fine and covers most cases. It covers some cases. It will not provide reliability against broken plugins; it's like Future.cancel(), it only works if you implement it. For most plugins, interrupting a running thread isn't useful - work isn't easily reverted. If you want specific plugins to use Future's I have no issue with importing the relevant APIs from Java or even from (small) third party libraries. > > >> As for the updater, simply seeing where the currently-running JARs are, is > >> not > >> enough, if an update introduces extra JARs as a dependancy. It's necessary > >> to > >> have an explicit list of all the dependencies. Unfortunately it's not > >> enough to > >> simply use the Class-Path attribute of the manifest of freenet.jar, because > >> that hard-codes the path to the other JARs, whereas we need it to be > >> variable > >> for packaging purposes. So, this information can only be figured out at > >> *package time* (for arbitrary package layouts), and the updater needs a > >> mechanism to read this information, and probably update that as well. To clarify, I suggest the solution to the Class-Path problem is simply not to include a Class-Path in the jar. > > > > You are planning to have a packaged version which is able to > > auto-update-over-Freenet? > > > > Currently class-path hardcoded freenet-ext.jar for convenience more than > > much else. 99% of installs use the wrapper. > > Any software package should support being installed into any arbitrary layout. > It's just good practise. You have to tell it where everything is somehow. At a minimum that involves a config file. If we are using the wrapper we can probably find the jars from that. If we are not I guess they could be configurable but it's messy IMHO. See, different definitions of elegance - don't impose yours on me if you don't want me to impose mine on you! Alternatively we could come to a civil compromise.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
