Since I am not on the list, please cc me on any replies. [Perl isn't used in the project, as much as the project uses an external perl module] Ok, then that's less of an issue.
> The project is over ten years old. It once used perl as it's scripting > engine, and long before any of the current developers got onboard a decision > was made to switch to guile (scheme). Do we sometimes regret it? Yes. Do > we want to de-emphasize scheme from some parts of the code? Yes. Would it > be a good idea to get completely rid of it? Not at all. I happen to like scheme. I don't know how Guile is as a technology to work with, but it has the advantage that it seems lively as project, and seems suited for your goals. Don't see a reason to drop it - I was assuming it and perl were living in the same niche. > As for the architecture, it's not too bad, and it's actually getting cleaned > up as a byproduct of the gnome 2 port. In an ideal world, we would a fair > amount of time to do code refactoring. But until we do everything I outlined > in the article, major organized refactoring (such as reworking dependencies, > or major architecture changes) which do not solve an immediate problem are > not likely to happen, and likely to do more harm than good in some cases. I agree - I am not saying to make grandiose plans and start working at a tangent to your users. The right way to do refactoring is a little bit every day. That's especially important in dealing with big refactorings - do them in small bits. Eventually, new developers coming in will see a project that shows it cares about simplicity, which is the most direct and effective way to encourage new developers. > > scary - for example, the goals page includes release information - and > > it quite out of date. It also includes a quite wrong description of the > > MVC pattern - which doesn't instill much faith in the benefit its use > > brings to the project. > Well, I mentioned in the article that the web site is is out of date and > misleading, so I fully agree... BTW, you mention in the article implementing a wiki in a way that made me think you might be talking about writing one. There are hundreds of existing implementation, in C, in Scheme, in Smalltalk... Just pick one and install it. It makes updating and improving the site so much easier that it is worth it the people doing the updating remain the same ones. And move all fast changing information to it, so anyone can update it - then users are unlikely to wait to the core developers to update it - they'll do it themselves. > > The "loose confederation of cooperating components" is probably one of > > the reasons you're seeing so much bit rot - reliance on fragile > > interfaces is what futile maintainance work is made of. > > Realistically for such a large code base, a monolithic application > (architecture wise) would be a nightmare. We do merge or split modules when > it makes sense and eases maintainability. I'm not saying to make it a monolithic application - somewhere in between. Read on. > The general architecture is fine (tough it suffered from lack of project > management and a half implemented module subsystem). The reason that we are > getting so much bit rot is usually that a complex but peripheral module > (postgres backend, qif-io-core, perl external bindings) These are all interface technologies. That isn't a coincidence. Interfaces, because they are at boundaries between you and another project, suffer more bitrot than other code. They are harder to find a maintainer for, because they require knowing more than just your project. So I'm just saying that you should be very selective about what interfaces you decide to include in the project. QIF sounds strategic (allowing users to convert). The others I don't know enough about to say, but every interface you can lose will make your life simpler. [core feature of DB is no information loss, no save] > The interim solution in 1.8.5 is the logfile player I wrote. Cool! > The plan in 2.0+ > is to use en embeded database, so save will go away. Ok. As long as you don't need to maintain it yourselves :-) > > In short, I think you need to consolidate - decide what technologies are > > earning their keep and which are simply a headache to work with, and > > dump some of them. Same for architectural ideas - choose a few goals, > > Sincerely, I don't see much to dump. > -Technically we could dump XML eventually. Unless you have something simpler that fills your needs, XML is a standard technology with lots of libraries. Might not be worth dumping. > -Dumping guile just to replace it with another scripting language is neither > realistic nor really usefull. Agree. > -Dumping g-wrap or alternatively swallowing it's codebase is a good long term > goal. > -GtkHTML has it's problem, but is absolutely essential for reports. > -Libghttp can be dumped (if it hasn't already), to my knowledge, nothing in > current working code requires it. > -Guppi no standalone replacement for this exists, but we are talking with the > gnumeric developers to see if we can spinoff their graphing engine. Rolling > our own from scratch would be a monumental waste of time. All sounds good. Especially if the gnumeric engine isn't forked, so that you keep sharing the maintainence. This might be enough - don't drop something you need, just drop everything you can live without replacing. It'll be easier for the developers the project has to deal with what remains, and it might actually make the project a more inviting place for new developers. [Importance of non-home users is that they bring their own coders] Ahh. I missed that. Nevertheless, seems to me you already have less eyes than balls to keep them on, so consider each connection carefully. Anyway, thanks everybody for working on a great project. First financial software I use, and I find it quite helpful. Using it has helped me develop my ideas about how to think of money. Daniel _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
