← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 12:50 | owen | What does it mean in the 3.0 Roadmap when the notes column in the table says "note" ? |
| 12:52 | Tumer has completed a search history feature for the opac? | |
| 13:12 | kyle | hey all, I'm trying to write a script that simulates daily usage (issues and returns only for now), and I can't seem to get C4::Circulation::Circ2::issuebook to work. |
| 13:13 | I set the %env var (branchcode, printer, queue) by hand, but I get this error: | |
| 13:13 | Can't use string ("/dev/lp0") as a HASH ref while "strict refs" in use at /usr/local/koha/intranet/modules/C4/Circulation/Circ2.pm line 839. | |
| 13:13 | any idea what's going on? | |
| 13:15 | it makes no sense. Line 829 is: if ($currentborrower eq $borrower->{'borrowernumber'}) { | |
| 13:15 | it's not even referencing %env | |
| 13:23 | kados | owen: it means that's the space for a note, but none has been written yet ;-) |
| 13:23 | owen: yes, search history feature is complete | |
| 13:24 | owen | In HEAD? I'll have to see if I can get it working on 101 |
| 13:24 | kados | owen: not a chance :-) |
| 13:24 | owen: I'm working on getting it up on 100 | |
| 13:24 | owen | HEAD's pretty broken right now I take it? |
| 13:24 | kados | owen: been working on it all day in fact :-) |
| 13:24 | owen: yea, but it's improving | |
| 13:40 | basically we just need to finish merging dev-week code into HEAD | |
| 13:41 | then we need to merge in all the bug fixes and patches to rel_2_2 into HEAD | |
| 13:41 | at that point the only difference between rel_2_2 and HEAD will be Zebra + all the newly developed stuff ... but at least the core will be stable | |
| 01:58 | hdl | hi |
| 02:00 | pierrick | hi hdl |
| 02:17 | hdl, where do I find a good documentation of serials in Koha ? | |
| 02:19 | btoumi | hi everybody |
| 02:21 | osmoze | hello too :) |
| 02:21 | btoumi | :=) |
| 02:22 | russ | hi there |
| 02:22 | hdl | pierrick: what kind of information do you need ? |
| 02:22 | pierrick | hi russ, btoumi & osmoze |
| 02:22 | russ | pierrick - not sure if this helps but here are some docs for the serials changes we have just made (they are in final testing with a client, once they pass there they will be committed) |
| 02:23 | pierrick | hdl & russ: I would like to understand how serials are managed, a functionnal documentation for first |
| 02:23 | hdl | pierrick: Does online help not help you ? |
| 02:23 | pierrick | hdl, which one. |
| 02:23 | russ | http://wiki.liblime.com/doku.p[…]d=kohaserialsspec |
| 02:23 | pierrick | ? |
| 02:24 | hdl | online help on a new subscription for instance or on edit page. |
| 02:24 | pierrick | hdl, there is the kohadocs.org manual, but it says the serials chapter is "to be completed" |
| 02:24 | oh sorry, I take a look | |
| 02:25 | russ | pierrick: we also have some documentation prepared, completed with online help |
| 02:25 | but i dont have my hands on it at the moment | |
| 02:25 | i can chase it all up tomorrow when the rest of the crew is back at work | |
| 02:25 | hdl | But if it is with how it is managed with koha tables, you are right, it is not explained. |
| 02:25 | pierrick | ok russ, thanks |
| 02:52 | chris | evening |
| 02:53 | pierrick | evening chris |
| 02:54 | russ or chris, do you know when the serials management improvement is planned to be implemented? | |
| 02:54 | (the one described in Liblime wiki) | |
| 02:55 | chris | its been written and is in testing by one of our clients at the moment |
| 02:55 | pierrick | great, so it will be an extension for 2.4 ? |
| 02:55 | and included in 3.0 ? | |
| 02:55 | chris | yep |
| 02:56 | we'll commit it to head | |
| 02:58 | should be in the next week or so, i havent worked on it, one of the other developers at katipo did it, and it should be some of his first big commits | |
| 03:00 | as soon as the it passes its testing, we'll get it committed | |
| 03:17 | ToinS | hi all |
| 03:22 | chris | hi toins |
| 03:22 | ToinS | chris: how are you ? |
| 03:26 | pierrick | hi ToinS |
| 03:26 | ToinS | hello pierrick |
| 03:27 | chris | good thanks, how are you? |
| 03:28 | the importance of using strict | |
| 03:28 | http://www.perlmonks.org/index.pl?node_id=494927 | |
| 03:29 | ToinS | lol |
| 03:32 | btoumi | hi toins |
| 03:32 | ToinS | hi btoumi |
| 03:32 | btoumi | lol |
| 04:52 | pierrick:desole je renvoi ca sur la liste | |
| 07:10 | pierrick | is there a dedicated screen for serials in the OPAC? |
| 07:10 | (I can't find it so I think no, but let's ask the experts :-) | |
| 07:36 | hdl | pierrick: there is a dedicated link taht leads to collection status. |
| 07:39 | pierrick | hdl, can you tell me where it is ? |
| 07:42 | is it possible to have more than one item for the same serial? | |
| 07:42 | I mean for example, 2 items of "Le Monde, N°12345" | |
| 07:43 | "Le Monde" is the collection | |
| 07:44 | hdl | pierrick: opac-serial-issue.pl |
| 07:44 | normally, yes, two different barcodes. | |
| 07:45 | But then you should receive twice (at the moment). | |
| 07:48 | pierrick | URL /cgi-bin/koha/opac-serial-issue.pl was not found on this server. |
| 07:49 | hdl | cgi-bin/koha/opac-serial-issues.pl?biblionumber=30 |
| 07:49 | pierrick | are the 2 items linked in some way ? Or are they just supposed to have the same serial.serialseq ? |
| 07:49 | same problem, I have an error 404, not a 500 | |
| 07:50 | kados | hi all |
| 07:50 | pierrick | hi kados |
| 07:50 | kyle | hey kados |
| 07:50 | kados | I've just sent an important email to koha-devel dealing with how to merge changes to Biblio.pm from dev_week and HEAD |
| 07:50 | if paul's around, I'd love some feedback on that | |
| 07:51 | hdl | pierrick: same serial.serialseq |
| 07:53 | opac-serial-issues.pl is in HEAD directory opac. | |
| 07:53 | pierrick | OK, as long as HEAD is all broken on my computer (due to the new koha.xml I suppose) I can't test |
| 07:54 | hdl | In rel_2_2 also |
| 07:56 | pierrick | hdl: you're right, I had made a typo in the URL :-) |
| 07:58 | hdl | :) |
| 07:59 | pierrick | is it possible to duplicate a subscription? |
| 08:00 | (because I want more than one item per serial issue) | |
| 08:01 | ... simply be using the same biblionumber, it's quite easy in fact | |
| 08:02 | hdl | :) |
| 08:06 | pierrick | after testing, with opac-serial-issues.pl I can't see how many items per issue I have. The screen is broken in subscriptions |
| 08:07 | (I hope the customer won't have more than 3 subscribtions, I will become hard to read :-/) | |
| 08:09 | kados | pierrick: getting the koha.xml to work is pretty simple |
| 08:09 | pierrick: I did mine yesterday | |
| 08:13 | pierrick | kados, I wanted to make it work this morning, but SAX keeps saying there is an encoding issue on a file (I suppose on koha.xml)... I have not much time today, so I'll do it next week |
| 08:30 | paul | pierrickn hdl, kados & btoumi_away, i'm back on this channel |
| 08:48 | kados | hey paul ... |
| 08:49 | paul | hey |
| 08:49 | kados | if you have a spare moment, please take a look at my mail to koha-devel asking questions about Biblio.pm |
| 08:49 | I am hoping to get dev_week merged this week | |
| 08:49 | but it's a lot of work ! | |
| 08:52 | paul: we don't need to export routines that aren't used outside of Biblio.pm, right? | |
| 08:52 | paul | (on phone) |
| 08:57 | pierrick | kados, right |
| 08:57 | kados, even better, a Perl convention to keep routines "privates" to a module is to precede their name with "_" | |
| 08:57 | kados | we seem to have lost &updateBiblio &updateBiblioItem and &updateItem in HEAD |
| 08:58 | pierrick: right, we should start doing that then | |
| 08:58 | pierrick: I'm ready to completely overhaul Biblio.pm | |
| 08:58 | pierrick | kados, OK, I add this to my coding guidelines draft |
| 08:58 | kados | pierrick: I'm going to go through every subroutine in there, check where it's used, clean it up, etc. |
| 08:58 | pierrick: if you post what you have to the wiki I'll add stuff as I find it | |
| 08:58 | pierrick | great ! That's a huge work. |
| 09:00 | kados | pierrick: the most difficult part is trying to figure out why things changed the way they did ... |
| 09:00 | pierrick | kados, I'll do it at the end of the day if I have time to finish my proposal :-/ |
| 09:00 | kados | pierrick: sweet, thanks |
| 09:01 | pierrick | kados, I've worked a lot on the reservation screen and I've realized that in modules, there are many routines written twice or more (I mean two routines doing the vey same thing) |
| 09:01 | kados | pierrick: yea, its crazy |
| 09:01 | pierrick: I'm not releasing 3.0 until all that junk is cleaned up | |
| 09:01 | pierrick: :-) | |
| 09:04 | what I'm doing | |
| 09:04 | I've got a 'cvsrepos' dir | |
| 09:04 | with three dirs inside: | |
| 09:04 | 22, 30, dev-week | |
| 09:04 | each has a koha dir inside with the cvs repo | |
| 09:05 | so I can go grep -r updateBiblio cvsrepos | |
| 09:05 | and find all the places in all three trees where a given sub is used | |
| 09:05 | pierrick | of course :-) |
| 09:06 | (I prefer using "find . -name "*.p[ml]" | xargs grep -wl updateBiblio", but it's a matter of choice...) | |
| 09:06 | kados | heh :-) |
| 09:06 | pierrick | using emacs macros is also a good solution to be efficient |
| 09:07 | kados | I'm confused about why updateBiblio, updateBiblioitem and updateitem are not present in HEAD |
| 09:07 | and I don't see any notes in the changelog | |
| 09:07 | pierrick | and you can't study the "cvs annotate"... |
| 09:08 | kados | paul: do you know? |
| 09:08 | what's cvs annotate? | |
| 09:08 | pierrick | ah ah :-) |
| 09:08 | let's give it a try on your C4/Biblio.pm :-) | |
| 09:08 | kados | pierrick: remember I'm not a programmer by trade ;-) |
| 09:10 | ahh, that's anice trick :-) | |
| 09:11 | cvs annotate C4/Biblio.pm |grep updateBiblio | |
| 09:11 | doesn't help much :( | |
| 09:12 | pierrick | of course, annotate is great for additions, not for deletions |
| 09:12 | kados | well, if someone removes updateBiblio, they should say they did and why! |
| 09:12 | pierrick | (and now) |
| 09:14 | kados | I guess I'm gonna assume those three routines are from koha 1.x and aren't relevant anymore |
| 09:14 | they're not used anywhere ... | |
| 09:16 | pierrick | if not used, where is the problem of removing? We should remove any useless routine I guess |
| 09:19 | kados | yep, doing that |
| 09:19 | paul: got another question for you ... | |
| 09:19 | paul | (still on phone, but throw your question) |
| 09:19 | kados | paul: what do you think of keeping marc-* tables in Koha and allowing a library to choose whether to use zebra or not |
| 09:19 | paul: is it too late to consider this option? :-) | |
| 09:27 | paul | kados : i'm back |
| 09:27 | kados | cool |
| 09:27 | paul | (in fact, I was here, but skyping with a tunisian contact ;-) ) |
| 09:27 | kados | sweet |
| 09:28 | paul | to answer your last question : no, it's not too late. even if i'm not sure it's a good solution. |
| 09:28 | because keeping marc_*_table is still possible for biblio.pm, it will be quite complex to keep SearchMarc.pm working with all those new features that rocks | |
| 09:28 | (like CQL...) | |
| 09:29 | kados | ahh ... true |
| 09:29 | unless ... | |
| 09:29 | we have two separate search screens for each ... like we do already | |
| 09:29 | there's a simple search screen written by chris for CQL | |
| 09:29 | and the advanced search written by tumer for zebra boolean | |
| 09:29 | paul | maybe that could be somewhere possible. |
| 09:29 | kados | and the old opac-main.pl and opac-search.pl |
| 09:35 | paul | about updateBiblio : is there a recent commit from me removing them ? maybe I checked & saw they were useless & removed them in a recent commit, as I made a lot of cleaning. |
| 09:35 | let me check... | |
| 09:36 | mmm... no, I can't see any specific commit about "cleaning code" | |
| 09:37 | kados | I think what we need ... is to define an API for Biblio.pm and Search.pm |
| 09:37 | that's step #1 | |
| 09:37 | so what are the operations that we need to support in the API | |
| 09:38 | for Biblio.pm for instance | |
| 09:39 | paul | I think that the API I had defined for Biblio.pm was quite good. So we could continue with it mostly. |
| 09:40 | and that would be very good for compatibility with everything if adding a biblio could just be NEWnewbiblio($dbh,$record,$framework) | |
| 09:44 | kados | paul: the API for 3.0? or 2.2? |
| 09:44 | paul | it didn't change from me, so it's the same. |
| 09:44 | but tumer did some changes i could not investigate yet | |
| 09:46 | kados | paul: why not just call then newbiblio instead of NEWnewbiblio? |
| 09:46 | paul | because newbiblio was the name for 1.x API, without MARC |
| 09:47 | kados | so can't we just delete the old one ? |
| 09:47 | in 3.0 i don't think we need to have 1.x code still in Biblio.pm | |
| 09:47 | paul | once MARC=OFF will be dead, we will be able to |
| 09:47 | kados | all MARC=OFF does it hide MARC, it doesn't change what happens behind the scenes ... right? |
| 09:48 | paul | nope. look at POD of Biblio.pm |
| 09:48 | it explain all of this | |
| 09:48 | ToinS is trying to commit on gna.org with svn since this morning. | |
| 09:48 | svn co is done, svn add fails. | |
| 09:49 | kados | cool |
| 09:49 | ok ... here's from the POD | |
| 09:49 | * MARC=ON : when MARC=ON, Koha uses a MARC::Record object (in sub parameters). Saving information in the DB means : | |
| 09:49 | - transform the MARC record into a hash | |
| 09:49 | - add the raw MARC record into the hash | |
| 09:49 | * MARC=OFF : when MARC=OFF, Koha uses a hash object (in sub parameters). Saving information in the DB means : | |
| 09:49 | - store them & update Zebra | |
| 09:49 | - transform the hash into a MARC record | |
| 09:49 | - add the raw marc record into the hash | |
| 09:49 | - store them & update zebra | |
| 09:50 | I'm a bit confused by this | |
| 09:50 | steps 2 and three are the same | |
| 09:50 | but step one in MARC=ON leaves you with a hash, but with MARC=OFF it leaves you with a raw MARC | |
| 09:51 | paul | the call parameter is different : MARC for NEW, hash for old |
| 09:52 | then, the other object is builded & both are stored (MARC & non-MARC) | |
| 09:52 | at the end, both have a MARC & non-MARC storage. | |
| 09:53 | kados | what is sub parameters? |
| 09:54 | paul | ? |
| 09:54 | kados | I don't see it anywhere |
| 09:55 | pierrick: do you understand the above POD? | |
| 09:55 | I'm still not understanding what the difference between MARC=ON and MARC=OFF is | |
| 09:56 | paul | adding a biblio with MARC=OFF don't give you the addbiblio.pl screen, but a highly different one. |
| 09:56 | very simple & hardcoded | |
| 09:57 | kados | couldn't we just get rid of that and use a simplified framework? |
| 09:57 | and turn off display of the MARC codes? | |
| 09:58 | paul | that's what I suggested to chris recently & he promised to give it a try |
| 09:58 | he seems quite happy with this solution | |
| 09:58 | kados | ok, I say we do this then ... |
| 09:58 | so we can unify the API | |
| 09:58 | paul | ;-) |
| 09:59 | kados | so here are the changes I'm proposing for Biblio.pm |
| 09:59 | 1. delete old 1.x routines | |
| 09:59 | 2. change NEWXXX to XXX | |
| 09:59 | change the name of all internal routines to _XXX | |
| 09:59 | dewey | kados: that doesn't look right |
| 09:59 | kados | dewey: right, I forgot the 3. :-) |
| 09:59 | dewey | kados: huh? |
| 10:01 | kados | paul: we should be able to eliminate REALXXX too |
| 10:01 | I see no reason to separate out the NEW and REAL routines ... we can just have one routine for each API call ... unless you disagree | |
| 10:01 | pierrick: any opinions on this? | |
| 10:02 | paul | kados: for sure, we don't need REAL... |
| 10:02 | if we get rid of MARC=OFF, Biblio.pm will be highly simplified ! | |
| 10:02 | kados | it makes troubleshooting very difficult |
| 10:02 | yea, we're getting rid of it :-) | |
| 10:03 | if we need to fix some stuff for katipo's clients then so be it | |
| 10:03 | but we need to clean up this API | |
| 10:03 | it's a mess | |
| 10:03 | I'm re-writing Biblio.pm from scratch :-) | |
| 10:04 | paul | imho, we don't need to rewrite biblio.pm from scratch. |
| 10:04 | we should be able to get something clean by : | |
| 10:04 | - keeping useful API (NEWnewbiblio for example) | |
| 10:04 | merging OLD & MARC subs in NEW | |
| 10:05 | - removing REAL, that is really useless | |
| 10:05 | - removing old-style API | |
| 10:05 | the last question being : is it interesting to keep using NEWxxxx ? | |
| 10:05 | why not having just xxxx ? | |
| 10:05 | good question ;-) | |
| 10:06 | kados | that's basically what I'm doing |
| 10:06 | but I'm starting with a new file | |
| 10:06 | and copy/paste in the stuff we're saving | |
| 10:06 | and i need to merge in Tumer's Zebra management functions | |
| 10:06 | paul | should be the best solution probably then. |
| 10:07 | kados | I tried cvs update -d -j Biblio.pm |
| 10:07 | but that was never going to work :-) a real mess :-) | |
| 10:08 | I'm also turning on warnings | |
| 10:08 | it'll be turned off before the 3.0 release | |
| 10:08 | but it's going to be necessary to troubleshoot in the meantime | |
| 10:08 | esp with mod_perl | |
| 10:11 | paul: do we need newbiblio as well as newbiblioitem? | |
| 10:11 | paul | yep, I have warnings=ON too |
| 10:11 | pierrick | I'm back... kados I read the log of the last hour |
| 10:11 | paul | this question is interesting... it depends on wether we decide to remove 1biblio = X biblioitems possibility that was with MARC=OFF |
| 10:12 | in this case, no need to have biblio & biblioitems tables. | |
| 10:12 | kados | right |
| 10:12 | paul | thus no need to have newbiblio & newbiblioitem ;-) |
| 10:12 | kados | I know that katipo needs to be able to group items of different itemtypes |
| 10:12 | but if we move itemtype to the item level | |
| 10:12 | I think that would solve that problem for them | |
| 10:13 | (it would also remove another barrier to standard MARC compliance) | |
| 10:14 | paul | be careful, as for UNIMARC itemtype is at the right place ! |
| 10:15 | (biblio level) | |
| 10:15 | because for UNIMARC, a different itemtype means a different "object", so a different biblio. even if the diff is only the publicationyear & not the itemtype ! | |
| 10:17 | kados | so maybe we need |
| 10:17 | bibliotype and itemtype | |
| 10:17 | paul: would that work for UNIMARC? | |
| 10:18 | pierrick: what do you think of the log? | |
| 10:18 | paul | yep, maybe. but upgrade 2.x => 3.0 will be really nice !!! |
| 10:19 | pierrick | OK, I've read the last hour log... |
| 10:19 | many things were said. | |
| 10:19 | kados | paul: in fact, not too bad ... it will be necessary to export all MARC records anyway |
| 10:19 | paul: to index in zebra | |
| 10:20 | pierrick | My opinion is the following: kados, please create a real discussion on koha-devel with all your propositions. Even if IRC is great for reactivity, it's bad for deep discussion as the one I've just read |
| 10:20 | paul | pierrick: ++ I almost wrote this here a few minuts ago |
| 10:20 | kados | paul: there are some highly specialized routines in Biblio.pm ... such as &modsubtitle &modsubject &modaddauthor |
| 10:21 | paul | that should be removed as well |
| 10:21 | kados | pierrick: of course, I will ... but we could talk for weeks about how to do this |
| 10:21 | pierrick: the first step is to define what my propositions are | |
| 10:21 | pierrick | yep |
| 10:21 | kados | pierrick: and to do so i need to chat with the original authors of the modules |
| 10:22 | btoumi_away | bye everybody |
| 10:22 | kados | pierrick: I'm putting together a wiki page with my new proposed api for biblio.pm |
| 10:22 | pierrick | great :-) |
| 10:22 | kados | paul: so all of those specialized routines can be handed by modbiblio now, right? |
| 10:22 | and &checkitems ... | |
| 10:22 | paul | yep. they were here because in Koha 1.x, subtitle & addauthors & subjects where in a different screen |
| 10:23 | (iirc) | |
| 10:23 | (& when MARC=OFF) | |
| 10:23 | kados | gotcha |
| 10:25 | pierrick | another question about Biblio.pm: shouldn't we separate biblio management and items management ? |
| 10:25 | items are used for circulation while biblio are used for search | |
| 10:26 | paul | maybe yes, but not sure. as items are also used for searching sometimes. |
| 10:26 | kados | yea, all are in the MARC record |
| 10:26 | at least currently | |
| 10:26 | paul | I think a package for MARC management & one for MARC search is better |
| 10:26 | kados | at devweek we discussed creating a separate holdings database |
| 10:26 | in zebra | |
| 10:26 | and i think it's a good idea | |
| 10:26 | but I'm not sure how hard it would be to do at this point | |
| 10:26 | paul | (but we decided to put this idea on feature for Koha 4 ;-) ) |
| 10:26 | kados | yea :-) |
| 10:27 | pierrick: in your view would we then have a Biblio.pm and a Holdings.pm ? | |
| 10:27 | pierrick | yes we have items in MARC record, but what we always use in code is the MySQL links |
| 10:27 | kados | pierrick: or would we keep everything in the Biblio.pm still? |
| 10:27 | pierrick | kados, yes, Biblios and Holdings are not the same |
| 10:27 | kados | interesting ... |
| 10:27 | in 2.x we use MySQL links for searching | |
| 10:28 | bu in 3.0 we use CQL or RPN | |
| 10:28 | pierrick | really ? |
| 10:28 | kados | yea, at least in tumer's stuff |
| 10:28 | don't know about chris's | |
| 10:29 | pierrick | when I have a barcode issued, I look in zebra to find the associated biblio? |
| 10:29 | kados | tumer's code allows this I think |
| 10:29 | I'm not sure if he's committed that bit yet | |
| 10:30 | pierrick: in fact, why not have a Holdings.pm | |
| 10:31 | pierrick: so in Biblio.pm, we'd have: | |
| 10:31 | newBiblio | |
| 10:31 | modBiblio | |
| 10:31 | delBiblio | |
| 10:31 | and in Holdings.pm we'd have: | |
| 10:31 | newItem | |
| 10:31 | modItem | |
| 10:31 | delItem | |
| 10:32 | and in Search.pm: | |
| 10:32 | getBiblio | |
| 10:32 | getItem | |
| 10:32 | right? | |
| 10:32 | paul: do we need more of an API that that? | |
| 10:32 | paul | & getBiblios to search in the catalogue |
| 10:32 | kados | ahh ... right |
| 10:32 | paul | that that ? no, that that enough I think |
| 10:33 | kados | in fact, it's quite simple then |
| 10:33 | pierrick | instead of newXXX I would prefer addXXX (consistency) |
| 10:33 | kados | good point pierrick |
| 10:33 | paul | ah ! good question : do we prefer new or add ! |
| 10:33 | I personnaly prefer new. | |
| 10:33 | kados | heh |
| 10:33 | paul | but I agree we just need to decide |
| 10:34 | pierrick | "new" is a adjective, while we want a verb |
| 10:34 | paul | other question : "mod" or "upd" ? |
| 10:34 | pierrick | "mod" or "upd" is the same for me |
| 10:34 | paul | pierrick: ++ |
| 10:34 | (for new/add) | |
| 10:35 | kados | ok, so addXXX |
| 10:36 | i prefer modXXX to udpXXX | |
| 10:36 | pierrick | we are also saying we prefer "addXxx" to "add_xxx" and "addxxx". |
| 10:37 | I don't mind, but it's important for consistency. | |
| 10:37 | paul | addXxx for me |
| 10:37 | kados | I prefer that |
| 10:37 | addXxx for me too | |
| 10:37 | pierrick | OK, "addXxx" |
| 10:37 | paul | meaning addXxxxYyyyZzzz if needed |
| 10:37 | kados | and it will be consistant in Biblio.pm, Holdings.pm and Search.pm |
| 10:37 | yep | |
| 10:46 | http://wiki.koha.org/doku.php?id=api | |
| 10:47 | paul: we've got a bunch of other exported methods in Biblio.pm ... | |
| 10:48 | things like MARChtml2xml | |
| 10:48 | pierrick and paul, should those be exported? | |
| 10:48 | I know that one is currently used in addbiblio for instance | |
| 10:50 | paul | MARChtml2xml will be necessary i think |
| 10:51 | kados | should that really be in Biblio.pm? |
| 10:52 | paul | probably, as it's really related to biblio editing |
| 11:01 | veki | hello, I was on one conference about open access to information and I proposed to people from African countries to use free software for their libraries at the universities. DO you have any list of universities that use Koha for their libraries? |
| 11:03 | kados | pierrick: do you agree that connection management for zebra should be handled in Context.pm? |
| 11:03 | paul | hi veki. |
| 11:03 | in which country ? | |
| 11:03 | veki | hi |
| 11:04 | pierrick | kados, yes of course |
| 11:04 | paul | because we have some users in south america (Argentina for example) |
| 11:04 | as well as in cyprus | |
| 11:04 | veki | I am right now in serbia and my http://www.gnucentar.org.yu |
| 11:04 | but I have conections with universities in Ghana, Nigeria, South Africa, Uganda, Zimbabwe | |
| 11:04 | paul | no university that I know are here. but you'd better ask on koha mialing list I think |
| 11:05 | kados | pierrick_leavin: should there even be dbh or zconn in Biblio.pm? |
| 11:05 | paul | we have some libraries in Nigeria |
| 11:05 | veki | ok, no problem, I just want to knwo that soneone is already using koha, because people rather use something that is already used by someone |
| 11:05 | paul | kados: no, I don't think so, as they are general management. |
| 11:05 | kados | paul: no to which? ... there should not be dbh or zconn in biblio.pm? |
| 11:06 | paul | they should stay in Context.pm I think |
| 11:06 | kados | paul: right now in Biblio.pm we have: |
| 11:06 | all subs require/use $dbh as 1st parameter and a hash as 2nd parameter. | |
| 11:06 | pierrick_leavin | kados, what do you mean exactly? you don't want to see "dbh" anywhere in Biblio ? |
| 11:06 | kados | pierrick_leavin: yes, that's what I mean I think |
| 11:07 | pierrick_leavin | kados, where do you move SQL queries ? |
| 11:07 | paul | the 1st parameter is useless I think |
| 11:08 | as Context.pm handles db handlers very well | |
| 11:08 | pierrick_leavin | paul++ |
| 11:08 | kados | pierrick_leavin: well, I suppose we _should_ abstract them out to a SQL.pm or something ... but I see that as a separate issue |
| 11:08 | pierrick_leavin | kados, did you see what I made with get_infos_of in C4::Koha ? |
| 11:09 | kados | pierrick_leavin: no ... is it in head? |
| 11:09 | pierrick_leavin | kados, yes |
| 11:09 | paul | pierrick_leavin: yes, I saw it, and i'm still unsure i'm happy with it. |
| 11:09 | pierrick_leavin | paul, why? |
| 11:09 | paul | (I'm afraid this could make too many small subs too much specialized) |
| 11:10 | kados | pierrick_leavin: i don't quite understand what it does |
| 11:10 | paul | but I may be wrong. my opinion is not definetly made |
| 11:10 | pierrick_leavin | paul, instead of what you say, you will have more generic sub |
| 11:10 | paul | mmm... that's what I wanted to write in fact. |
| 11:10 | pierrick_leavin | the purpose is to avoid too many SQL joins |
| 11:11 | kados, find where it is used | |
| 11:11 | paul, we'll talk of it on monday if you want | |
| 11:11 | paul | ok |
| 11:12 | pierrick_leavin | I would like to go now, I take the car tonight, many things to do before leaving Paris... |
| 11:13 | kados | pierrick_leavin: ciao |
| 11:13 | pierrick_leavin | bye bye |
| 11:17 | veki | guys, i will wive your address to some librarians so yo can help them if needed. I hope that this is OK for you. |
| 11:18 | I will download koha and try it in one library here and I will give your address to some librarians | |
| 11:28 | paul_away | bye & see you on friday |
| 11:29 | (on monday pierrick won't be here & me neither, as we have a meeting with a university interested by Koha. not sure to be back at 20 for the meeting) |
← Previous day | Today | Next day → | Search | Index