Looking Deeper into Forges, And Not Liking What I See - esr(esr.ibiblio.org)
esr.ibiblio.org
Looking Deeper into Forges, And Not Liking What I See - esr
http://esr.ibiblio.org/?p=1295#more-1295
4 comments
Actually, he says that he may work on refactoring an existing forge project to add the features he deems necessary to free it's users from the "data jail."
No idea if that will really happen, but if so it's a tad better than the normal complain-but-do-nothing approach it's so common to find.
No idea if that will really happen, but if so it's a tad better than the normal complain-but-do-nothing approach it's so common to find.
I think he's also looking for ideas, notice several commenters on his blog have already provided links to other projects. He does that frequently, sometimes explicitly; as when a few months ago for example he asked for alternative 1911-based concealed carry guns.
They couldn’t have done it without either (a) duplicating a significant number of SQL queries in some kind of ad-hoc tool (begging for maintenance problems as the SQL schema changed) or (b) prying the SQL queries loose from the GUI and isolating them in some kind of service broker, either an Apache plugin or a service daemon, that both the web interface and a scripting tool could call on.
An "Apache plugin or service daemon"? It may just be me, but he sounds like a crazy person here. Oh, wait.
An "Apache plugin or service daemon"? It may just be me, but he sounds like a crazy person here. Oh, wait.
It's like he has never heard of MVC.
It's like you haven't noticed he is trying to break data out of the web jail. MVC is an in-process architecture. Evidently, he's thinking about an inter-process architecture that could be fronted in multiple ways.
There is nothing "in-process" about MVC. I can access ActiveRecord objects just as easily from an IRB as from a Rails action, and I can drive a REST API just fine from curl. He's simply crazy.
Your inter-process service broker is called "MySQL".
This may not be the best architecture.
This may not be the best architecture.
This is a followup to "Three Systemic Problems with Open-Source Hosting Sites", http://esr.ibiblio.org/?p=1282 .
Really, is it so hard to roll your own?
I did, and it was trivial: http://repo.cat-v.org
I did, and it was trivial: http://repo.cat-v.org
I must just be missing it, but does yours implement mailing lists, issue tracker, a scriptable release process, and have the entire project history including lists and issues easily accessible as downloadable snapshots?
If not, then it seems to be more an example of what he's railing against rather than a trivial solution to his perceived problem.
If not, then it seems to be more an example of what he's railing against rather than a trivial solution to his perceived problem.
(Disclaimer: firmly tongue in cheek, I'm a long-term and very happy desktop Linux user--though seriously, how many open source DVCS projects are there by now?)