The tool is impressive, but is definitely possessed of a few quirks -- doubtless this derives from the Beta nature of the thing. How should we handle their ... it isn't a fork ... derivative work? I've not "gotten my hands" dirty with our, or the Openbook code, enough to know if it would be possible to phase in additions from their back end. Alternately, could we replace the koha back end with theirs, in effect merging the two projects while preserving the Koha look and feel? That would get Koha full MARC functionality, especially if we wait for them to debug further. How seperate is the HTTP side from the database, etc side? I know I'm just blowing smoke, but I'd like to see us "get something" out of all the work they have put into their project, while preserving the (currently) more stable/production grade Koha code as much as possible.... I still have some odds and ends I've seen in commercial applications that I feel would be logical additions to both of the projects. [Good heavens I wish the had merged more of the code back while they were in development.... rather than just rewriting everything. Sigh.] Nick ...hoping to see the two projects move together, not apart.
Devil's advocate thought here... what if we were to simply, well, do a turnabout on the Openbook code? (ie, use it as the starting point for a new version of Koha?) Or, alternately, bring the two applications in close enough alignment so that no alterations be made to the databases behind them? Forgive me for suggesting it, but it might be the easiest way to avoid having two competing tools (forcing users of both to pick one feature set over another) out there.... Brainstorming, NSR ...who notes that usually, in a storm, one gets wet.
* Nicholas Stephen Rosasco <nsr4n@tetra.mail.virginia.edu> [010717 05:01]:
Devil's advocate thought here... what if we were to simply, well, do a turnabout on the Openbook code? (ie, use it as the starting point for a new version of Koha?) Or, alternately, bring the two applications in close enough alignment so that no alterations be made to the databases behind them?
Could well be a plan, Id need to look at their code more. When it all boils down to it, its all just SQL *grin*
Forgive me for suggesting it, but it might be the easiest way to avoid having two competing tools (forcing users of both to pick one feature set over another) out there....
Yep, precisely, id dearly like to not get into the openbsd, freebsd kinda thing. Tis mainly why am I silent on the fork issue on the main list. Im just glad you and stuart have brought it up. Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
On Tue, 17 Jul 2001, Chris Cormack wrote:
Could well be a plan, Id need to look at their code more. When it all boils down to it, its all just SQL *grin*
As near as I can tell, all of their released code is PHP. I think OpenBook really is a complete rewrite without any Koha code at this point. The database schema is also radically different. So it's not a fork, just a duplication of effort. :( Steve.
On Tue, Jul 17, 2001 at 02:28:53PM -0700, Tonnesen Steve said:
On Tue, 17 Jul 2001, Chris Cormack wrote:
Could well be a plan, Id need to look at their code more. When it all boils down to it, its all just SQL *grin*
As near as I can tell, all of their released code is PHP. I think OpenBook really is a complete rewrite without any Koha code at this point. The database schema is also radically different.
So it's not a fork, just a duplication of effort. :(
Steve.
Hi Steve Yeah after looking at the code, (near 20k lines of php). Id have to agree, it is a complete rewrite. Which is a real shame. Ok, on to more mundane things, i have put up koha-1.1.1.tar.gz on sourceforge, not on www.koha.org yet and no release notes yet. But I thought id tar it up and put it up there, just so that i tarred it up and put it up there. (Ive been meaning to for ages) So if anyone has time, if they can take a look, spot any big mistakes, and then if its not too bad, ill do a general release. Then we can start adding in our new marc code, and changing the database structure etc. I spent an afternoon with Monty Widenius (of mysql fame) last week, talking about how to optimise mysql. So I have a ton of ideas on how to speed up koha. So im keen to work on that. Hence i figured lets get 1.1.1 out so we can break stuff :-) Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
Well i would have put the file up, If i could get it to stick. Sometimes sourceforge does weird stuff. Ill try again Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
* Nicholas Stephen Rosasco <nsr4n@tetra.mail.virginia.edu> [010717 04:43]:
The tool is impressive, but is definitely possessed of a few quirks -- doubtless this derives from the Beta nature of the thing.
Yeah its nicely done ;-)
How should we handle their ... it isn't a fork ... derivative work?
Tis a tricky thing, it pretty much fits the definition of a fork, which is legal and fine under GPL, thus i have no issue with it. I dont think they understand what a fork is, and thus are overly defensive about it.
I've not "gotten my hands" dirty with our, or the Openbook code, enough to know if it would be possible to phase in additions from their back end.
I havent really looked at their backend, what I do know is that steve has come quite far in marc support for koha, in that it can be imported and modified now. Which as far as I can tell was the main difference.
Alternately, could we replace the koha back end with theirs, in effect merging the two projects while preserving the Koha look and feel? That would get Koha full MARC functionality, especially if we wait for them to debug further.
I think the path Steve is on will lead to more robust code, and more nicely defined cataloguing API. Having said that i havent got down into the guts of the openbook code.
How seperate is the HTTP side from the database, etc side?
Its PHP so quite tightly knit, there is quite a look of functionality mixed with interface code. One of the main reasons I started work in perl is that it is easier to achieve interface/code separation.
I know I'm just blowing smoke, but I'd like to see us "get something" out of all the work they have put into their project, while preserving the (currently) more stable/production grade Koha code as much as possible....
Oh for sure, so would I.
I still have some odds and ends I've seen in commercial applications that I feel would be logical additions to both of the projects.
Yep, feel free to keep suggesting/nagging ... its how these projects work :-)
[Good heavens I wish the had merged more of the code back while they were in development.... rather than just rewriting everything. Sigh.]
You and me both, if only they had contributed to the cvs tree, instead of forking their own project. But now if we can bring them back together, that would be great. Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
participants (3)
-
Chris Cormack -
Nicholas Stephen Rosasco -
Tonnesen Steve