- Koha-devel - lists.koha-community.org

Re: [Koha-devel] Re: A Win32 circulation client (beginning stages)
by Ambrose Li 19 Jan '03

19 Jan '03

Hi, On Sun, Jan 19, 2003 at 05:16:57PM +1300, Patrick Quinn-Graham wrote: > That would be a good idea, although to a certain extent it's > just as easy to directly connect to the database. The problem with directly connecting to the database is that you will need to duplicate all the logic in the existing CGI code. So, since there is no code reuse between the CGI scripts (written in Perl) and the Win32 client (written in VB), when people start adding functionality to the CGI, you will need to add identical functionality to the VB client. After a while, this might get frustrating. About the telnet client I mentioned earlier, it seems that it is broken quite badly and will need to be rewritten. But it would likely not be rewritten until Koha is better modularized. > I'm not sure how to go about starting to help with > modularization... But m willing to give anything a go. > > How far away is 2.1 likely to be? My main reason for doing > stuff now is that I'm currently unemployed (I'm a student, and > it's summer), and while doing a course, it's not anywhere near > full time (again, it's summer). > > Likely by the time it is released, I'll be back in a full time > course. I think someone else might be better to answer these. -- Ambrose Li <a.c.li(a)ieee.org>

1 0

[Bug 161] New: buildrelease gives error messages during normal operation
by bugzilla-daemon＠wilbur.katipo.co.nz 18 Jan '03

18 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=161 Summary: buildrelease gives error messages during normal operation Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Installation AssignedTo: a.c.li(a)ieee.org ReportedBy: a.c.li(a)ieee.org QAContact: koha-devel(a)lists.sourceforge.net During normal operations, running buildrelease gives mv: /tmp/koha-1.3.2/intranet-cgi/misc/bulkmarcimport.pl: No such file or directory I would have copied the docs from from /root/docs, but I couldn't find it. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

Re: [Koha-devel] Koha and testing
by Nathan Gray 18 Jan '03

18 Jan '03

Test::Debugger has made it to CPAN. I would like to have it considered as the testing module for Koha, because it is backwards compatible with Test.pm, which has been a part of the standard Perl distribution since Perl 5 came out. I personally prefer the Test.pm interface to the Test::More interface. However, since Test::More has made it into the standard Perl distribution starting with version 5.8.0, it may be preferable to use that module. The part of Test::Debugger that I value most is the debugging it logs. I do not know what logging capabilities Test::More has. Ed Summers may know, as he has used it for other projects. Once we come to a consensus, we should pick a few key modules and write a few tests for them. Ideally, each module should have at least one test script (if it doesn't do anything worth testing, why is it a module?). Most modules shouldn't have much of a test script, but a few will probably undergo a rather intense testing process during 'make test.' So which modules do we test first? And Ed, Pate, and the group, which test module shall we choose? kolibrie On Wed, Jan 08, 2003 at 08:56:10AM -0600, Ed Summers wrote: > PS. I'd be interested in hearing what your motivation was for creating another > testing framework and how it is different from Schwern's Test::More.

1 0

A Win32 circulation client (beginning stages)
by Patrick Quinn-Graham 18 Jan '03

18 Jan '03

Firstly: let me apologise - I posted this to koha-win32 as well. I've only come across Koha in the last few days, and am certainly excited by what I see: it's about time there was an opensource project like this. My one thing is: I'm not entirely sure I like the idea of doing Circulation type things through a web browser. So, here's the bit where I risk being unpopular: I've started writing a Windows client, for now I've only just started, but intend to do at least issueing/returning of materials. It's written in VisualBasic, so unfortunately probably won't be easily ported anywhere else, but so far doesn't use any non-standard controls, so it could be possible. It's currently sitting at a measly 132kb. (Plus, of course the VB stuff). It access the Koha system by connecting directly to the mySQL database using Microsoft Remote Data Objects and the myODBC connector, and authenticates based on the auth table. (I'm not sure how passwords are protected in there at the moment, as I just made up that part of my application - it md5's them, and stores them that way). Would any one else find this useful? If I release it, it will be under the GPL - it's not really based on Koha code, but I think it's only right. Just a little bio on me: I'm an 18 Software Engineering student at Victoria University (Wellington, New Zealand) - 2003 will be my second year, did all the Library Automation software stuff at my old High School - there we used the MUSAC Library Manager software, so have a reasonable understanding of at least the areas I'm working on here :-). If you want to try a really really early version of it, I'll put one up on my website (just need to recompile). Thanks for your reading time! Patrick.

1 0

[Bug 160] New: New book funds don't show up in list unless they have a budget
by bugzilla-daemon＠wilbur.katipo.co.nz 17 Jan '03

17 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=160 Summary: New book funds don't show up in list unless they have a budget Product: Koha Version: 1.2.3 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Parameters AssignedTo: tonnesen(a)cmsd.bc.ca ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net When you add book funds, they don't show up in the list until you have added a budget for them. This makes it seem like the book fund addition didn't work. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 159] New: Item search during full acquisitions doesn't display results properly
by bugzilla-daemon＠wilbur.katipo.co.nz 17 Jan '03

17 Jan '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=159 Summary: Item search during full acquisitions doesn't display results properly Product: Koha Version: 1.2.3 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Acquisitions (Full) AssignedTo: chris(a)katipo.co.nz ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net Searching for a record when making acquisitions shows a list of hash references instead of a list of matching items. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

RE: [Koha-devel] fulltext searches
by Anthony W. Youngman 17 Jan '03

17 Jan '03

Another thing to watch out for, which google has fallen into ... When looking for an EXACT MATCH, eg "The Lord of the Rings", the google search page comes up and says "words like 'of' and 'the' are extremely common and will be ignored"! Huh! I asked for an EXACT MATCH !!! Cheers, Wol -----Original Message----- From: paul POULAIN [mailto:paul.poulain@free.fr] Sent: 17 January 2003 09:44 To: Tonnesen Steve Cc: koha-devel(a)lists.sourceforge.net Subject: Re: [Koha-devel] fulltext searches >Just something to be aware of. > yep, thx to point this, which i ignored ! This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 9911 7799, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333.

1 0

fulltext searches
by Tonnesen Steve 17 Jan '03

17 Jan '03

IRC Discussion about fulltext searches: http://www.haz.cmsd.bc.ca/cgi-bin/kohalog.pl?date=15Jan03&refresh=&firstlin… The one caveat I found is that search terms of three characters or less are discarded. So if you do a fulltext search for "rabbit fur" you will get results regarding rabbits, but with no relevance placed on the word fur. Also, doing a fulltext search for the word "fur" will always return 0 hits. Searching for "furs" may return some hits, because it is a four letter word. In my current setup, I am using "like" searches if one or more search terms are three letter words, and fulltext searching if all search terms are longer than 3 letters. Just something to be aware of. The database I'm working on has about 600,000 records (almost 2,000,000 items), and initial "like" style searches complete in about 10 seconds or less, while fulltext searches complete in under 2 seconds. I don't know how fair this comparison really is as I used "car" for my like-style query nd "cars" for my fulltext query, but it gives you an idea of the difference in speed. I've also got caching working, so subsequent searches on the same term (ie looking at page 2 of the results) complete in under a second. Steve.

2 1

Re: [Koha] some thoughts about cataloguing and acquisition (important)
by paul POULAIN 17 Jan '03

17 Jan '03

I think i must explain some things about 2.0 version... The Database exists in 2 forms : * "standard db" : the DB coming from the 1.2 version * "MARC-DB" : the MARC one. A parameter tables maps marc fields and standard-db ones. The new 2.0 guarantees that both DB are always synchronised. That's why it was long to write, and to debug. But, now we have a big advantage, as the user can decide to use MARC or non-MARC interface. In both cases, the 2 databases are living. If you choose the MARC one, the parameter tables provides the following features : * support any MARC flavour : just define what 100$a, 200$a... mean * support what you want in your MARC flavour : 100$a => used 100$b => used, but less important, 100$c => ignored The manual MARC cataloguing tool is ready in 1.3.3, and used by a french library in France. My question was not about marc/non marc, my question was to have advices for a deepest separation between acquisition and cataloguing. I repeat that here, in France, there are almost no librarians that enters manually their biblios : universities have a common pool, the National Library (BNF) provides a cdrom with 4 millions of UNIMARC notices, and Electre provide a commercial one with recent books. So most ils separate acquisition and cataloguing, as librarians "spend not more than 10 mn a week on cataloguing" as mailed me a french koha-addict ! Let's continue your answers/ideas/... on this topic, i'll conclude and propose something (on the wiki) next week. you'll be informed of my proposal when ready, and get the opportunity to comment it too ! Note : i plan to do something SIMPLE (from a developping time point of vue) for the 2.0 release which should occur in a month (at least for a RC one) In 2.0.1, I expect to improve it (i WILL improve it if it's funded by someone !) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

Re: some thoughts about cataloguing and acquisitions [important]
by Stephen Hedges 16 Jan '03

16 Jan '03

Hi, Paul, and thanks for opening an interesting topic - I think that a strong acquisition component would be a very valuable asset for Koha. In fact, I think acquisitions are much more important than cataloging. That means that I support your idea of separating the two, so it would be easier (to my mind) to focus development effort on acquisitions. If they are not separated, then I think cataloging should at least be handled as a sub-task of acquisitions. My thoughts are based on my experience with library users and librarians. We have found that library users appreciate the ability to make purchase suggestions and see what the library has on order, even place reservations on items before they arrive at the library. In other words, a good acquisitions system allows users to see not only what the library has, but what the library WILL have, and also gives them the power to suggest and reserve things the library has not ordered. That means the acquisition system needs to deal in records that are nearly complete, so people can search for items by title, author, ISBN, subject, etc. Cataloguing, in that case, merely adds the "labeling" to the item once it arrives, i.e. barcodes, spine labels, etc. The item has already been cataloged in all other respects as soon as it is ordered. As for librarians, I had a conversation with the tech guy from Worthington Public Library who suggested that they might be willing to put money toward a really good Koha acquisitions system, one that would allow the librarian to automatically search for an item and compare prices from several different vendors and download any MARC records available from vendors with a minimum of effort on the part of the librarian. He had other thoughts, as well, because he had been wrestling with searching for a good acquisitions system for some time, but I unfortunately can't remember them now. Both of these experiences lead me to believe that any ILS that wants to be competitive in the future should pay close attention to its acquisitions component. I think both library users and librarians are going to demand much more functionality than what is currently available in most ILS acquisitions systems. Stephen H. > I want here share some ideas for the 2.0 version > of koha, around > cataloguing and acquisition. > > Most ILS, in France at least, separate > cataloguing and acquisition. > * *cataloguing* is often done through a CDROM > (from the BNF for example) > : the librarian download from the cd the biblio > in MARC format, which is > included in it's ILS. The cataloguing refers only > to BIBLIO notice, not > items and how they arrive in the library. > * *acquisition* referers to how "books" arrive in > the library (and > includes items) > > In koha, at the moment, there is no distinction > between those 2 topics : > look at koha main page, there is only a > "acquisition" picture, which > includes cataloguing and acquisition in fact. > I want to begin de debate to see if it's a good > idea to distinct > acquisition and cataloguing in 2.0. > It would mean : > * in mainpage => 2 links for cataloguing and > acquisition > * acquisition => works almost like the normal > acquisition system of the > old version : search for a supplier, enter a > little part of the biblio... > * cataloguing => > - if marc is selected : works like the > acqui.simple in 1.3.3 (see > demo.koha-fr.org) > - if marc is not selected : works like the 2nd > part of the normal > acquisition in 1.2 : enter the biblio details. > this supposes a new parameter in the > systempreferences table. > > One other idea : it would enable a "suggestion" > feature in the opac : > readers could suggest books to add, which could > be stored in the > "acquisition" part of koha, in a "to validate" > status. > > From a developper point of vue, this means : > * duplicating biblio table to acqui_biblio table > * split normal acquisition in 2 parts > * change normal acquisition to write acqui_biblio > table and not biblio > * create some screens to link the acquisition > part and the cataloguing one. > some work, but not too much i think (if someone > wants to fund it, send > me a mail :-) ). > > Of course, if you create a book in the > acquisition part, all what you > typed would be auto-copied when entering the > cataloguing part :-) > So there should not be too much more work for the > librarian/cataloguer > (but a few, anyway : this would add screens, so, > more clics) > > -- > Paul POULAIN > Consultant indépendant en logiciels libres > responsable francophone de koha (SIGB libre > http://www.koha-fr.org) > >

1 0