Timestamps are in GMT/BST.
[4:06] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:06] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:06] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[4:06] [freenode-connect VERSION]
[4:08] * ClaudiaJuergen (n=Miranda@pc5102.ub.uni-dortmund.de) has joined #duraspace
[4:08] <ClaudiaJuergen> good morning all
[4:30] * ClaudiaJuergen (n=Miranda@pc5102.ub.uni-dortmund.de) Quit ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
[5:03] * grahamtriggs (n=trig01@195.128.10.96) has joined #duraspace
[5:30] * RichardJones (n=richard@94-194-200-240.zone8.bethere.co.uk) Quit (Read error: 104 (Connection reset by peer))
[7:43] * bradmc (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) has joined #duraspace
[8:05] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:12] * bradmc (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) Quit (Read error: 104 (Connection reset by peer))
[9:23] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) has joined #duraspace
[11:27] * ben_atmire (n=ben_atmi@213.219.159.242.res.static.edpnet.net) has joined #duraspace
[11:29] * bradmc (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) has joined #duraspace
[12:00] * rrodgers (n=rrodgers@pool-173-76-16-252.bstnma.fios.verizon.net) has joined #duraspace
[12:03] <rrodgers> Is it Gardners' Question Time (aka committer's weekly IRC)?
[12:04] <mhwood> My calendar says it is.
[12:04] <rrodgers> we seem to be in the minority, though mhwood
[12:05] <mhwood> grahamtriggs just answered a question over in #dspace a minute or so ago.
[12:06] <grahamtriggs> rrodgers: any advise for accessing some particularly thorny roots?
[12:06] <rrodgers> grahamtriggs: dynamite
[12:08] <grahamtriggs> thanks. my sunflowers have now shot up to 100ft - although there is nothing between the head and the ground
[12:10] <rrodgers> (describes many software users, but I digress)
[12:11] <grahamtriggs> rrodgers: I would have put that down as the reciprocal problem
[12:12] <bradmc> This is the time. As mentioned in email, I'm not really available, so if one of you wants to chair, please do so. You might start with considering quorum, or lack thereof. :(
[12:12] <rrodgers> It might be the case that since we are now focussed on 1.6, we need StuartL, hence a later time slot?
[12:16] <grahamtriggs> There only seems to be three of us participating at the moment, and half of those are attending to their blooms. Shall we announce a reconvening at 9pm BST (4pm Eastern?, stupid o clock down under) and see if anyone turns up then?
[12:17] <mhwood> It's worth a try.
[12:17] <rrodgers> Agreed
[12:18] <rrodgers> see you all at 4 then
[12:18] * rrodgers (n=rrodgers@pool-173-76-16-252.bstnma.fios.verizon.net) Quit ()
[12:24] * mdiggory (n=mdiggory@nmd.sbx10180.carlsca.wayport.net) has joined #duraspace
[12:48] * grahamtriggs (n=trig01@195.128.10.96) has left #duraspace
[12:58] * mdiggory (n=mdiggory@nmd.sbx10180.carlsca.wayport.net) Quit (Read error: 104 (Connection reset by peer))
[12:58] * mdiggory_ (n=mdiggory@nmd.sbx10180.carlsca.wayport.net) has joined #duraspace
[12:58] * mdiggory_ is now known as mdiggory
[13:46] * ben_atmire (n=ben_atmi@213.219.159.242.res.static.edpnet.net) Quit ()
[14:30] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace
[15:28] * bollini (n=chatzill@87.10.22.119) has joined #duraspace
[16:04] <stuartlewis> Morning all - is the meeting still on now?
[16:05] * lcs (n=lcs@serenity.hul.harvard.edu) has joined #duraspace
[16:05] <bollini> I'm here
[16:06] <mhwood> Some of us thought it was 4 hours ago but we postponed it when we saw how few we were.
[16:06] <stuartlewis> Yep - should have been then afaik. 4am is too early. I tried for a while, but it got too hard.
[16:07] <bollini> yes... 16gmt is too difficult to me
[16:07] <stuartlewis> Would a 6PM GMT time (2 hours before now) be a good fit for everyone instead each week?
[16:07] <grahamtriggs> looks like a couple more online now. Guess we should give it a couple of minutes for others to join. Start tabling about topics??
[16:07] <grahamtriggs> stuartlewis: no, bad time for me - right bang in transit time
[16:08] <mhwood> Topic: script wrappers etc. for commandline tools
[16:08] <grahamtriggs> unless I get a standing agreement at work to disappear early for the meetings
[16:08] <stuartlewis> Topic: stats update
[16:09] <stuartlewis> Topic: authority control update
[16:09] <bollini> Topic: make community admin configurable - update
[16:09] <grahamtriggs> mhwood: how about scripture wrappers? why bother with all these modern languages when latin will suffice?
[16:09] * rrodgers (n=rrodgers@pool-173-76-16-252.bstnma.fios.verizon.net) has joined #duraspace
[16:11] <stuartlewis> Graham wants to ad eundum quo nemo ante iit
[16:12] <rrodgers> hey all - my topic is just various 1.6 updates
[16:12] <lcs> any fundamentalists want to implement script rapture?
[16:12] <mhwood> So I suppose Tcl would be heresy.
[16:12] <stuartlewis> Did anyone have a chance to look at http://jira.dspace.org/jira/browse/DS-321 'DSpace command line shell'?
[16:13] <stuartlewis> If so, what did you think?
[16:13] <rrodgers> yes - seems fine with the possible exception of an lcs issue - return codes
[16:14] <stuartlewis> Yes - not tried that yet. But the code executes the class in the same thread, and if the thread kills itself with a System.exit(x) then it should just work.
[16:14] <lcs> haven't looked at the code yet but the config looks good, though (a) why not just multiple <class> elements, (b) add syntax to explicitly allow user-specified command args.
[16:14] <stuartlewis> a) Wasn't sure if the parser would guarantee the ordering of elements
[16:15] <stuartlewis> b) Yes, would be a good extension. Just wanted to try something simple out.
[16:15] <lcs> there might be a problem running multiple commands when main uses System.exit.
[16:16] <stuartlewis> Good point - but if one exists, presumably that is because there is a problem, so you might not want the rest of the commands to run?
[16:16] <lcs> xml parsers are supposed to preserve ordering, fwiw.
[16:16] <stuartlewis> Having them numbered also helps to pair them up with their arguments
[16:17] <lcs> arguments ought to be a child element, then
[16:17] <stuartlewis> Good point
[16:17] <lcs> most main()
[16:17] <lcs> (oops) most main()'s call exit(0) on successful completion..
[16:18] <grahamtriggs> what about re-using ant, and defining the processes as forked tasks? http://marc.info/?l=ant-user&m=102264135822957&w=2
[16:18] <stuartlewis> I've tested the compound commands, and they execute sequential ly OK.
[16:18] <stuartlewis> grahamtriggs: Richard Jones had problems with that: http://chronicles-of-richard.blogspot.com/2007/03/crawling-like-ants.html
[16:19] <stuartlewis> Not sure if they were forked though.
[16:19] <rrodgers> also small name quibble - to me a shell is interactive - how about launcher, loader?
[16:21] <stuartlewis> launcher maybe good (it isn't 'loading' anything)
[16:21] <stuartlewis> OK - so there are some nomenclature issues, some config refinement issues, and some testing to be done. But other than that, is everyone happy with the approach, or is there a different better approach?
[16:21] <rrodgers> not a big deal - shell is economically short
[16:22] <mhwood> I like not having to look up those long class names.
[16:22] <stuartlewis> For 1.6 at least, we can keep the scripts, and make it an option for use that people can try out?
[16:22] <rrodgers> I'd say as long as we leave existing stuff (so we don't break crons, etc)
[16:23] <mhwood> Does this satisfy the people who dislike distributing platform-specific scripts? (Are any of them here?)
[16:24] <stuartlewis> Ok - so unless anyone has a problem with it, I'll try and find some time at the weekend (as well as moving house) to make the requested changes (name / config file)
[16:24] <stuartlewis> mhwood: I hope it does.
[16:24] <rrodgers> Your solution is so lightweight, I see no reason not to include it
[16:25] <stuartlewis> Cool - glad everyone is happy. Next topic?
[16:25] <bollini> stats update?
[16:26] <stuartlewis> mdiggory: You around?
[16:26] <mdiggory> ping
[16:27] <mdiggory> looks like I have some catching up
[16:27] <stuartlewis> mdiggory: Hi! :) We were just hoping for a quick update on your stats work.
[16:28] <mdiggory> I suppose you are...
[16:29] <mdiggory> rather entrenched in that atm
[16:29] <mdiggory> Still porting presentation into 1.6.x
[16:29] <mdiggory> and testing solr + service deployment
[16:30] <stuartlewis> Is there anything any of us can be doing to help out?
[16:30] <mdiggory> of course... the timeframe I suggested last week is turning out to be optimistic
[16:31] <mdiggory> well, we have grahamtriggs here today, we never formally clarified the usage of dspace-services in 1.6 with you
[16:31] <grahamtriggs> otherwise, is there any way to shortcut it - only put the barest bones of presentation in there (ie. a download count on an item), with the rest of the presentation to follow in a second RC, or .1 release?
[16:32] <mdiggory> grahamtriggs: yea... it will be bare bones... have we established a formal cutoff date for the rc?
[16:32] <stuartlewis> Ideally end of the month
[16:32] <stuartlewis> (1 week away)
[16:32] <stuartlewis> But if we can't hit that, we hit that. So don't bust a gut over it.
[16:33] <stuartlewis> But if we can't hit that, we can't hit that. So don't bust a gut over it.
[16:34] <mdiggory> much more is going on that stats/services for us ATM. delay is more resources and time than strategy / implementation problems
[16:34] <stuartlewis> Does that sound OK for a timescale, or not long enough?
[16:34] <grahamtriggs> mdiggory: dspace-services - is there anything to clarify? My only concerns with what might be in 1.6 is if anything is pushed up into the app server layer, or there are separate processes to be run.
[16:34] <mdiggory> grahamtriggs: for statistics we run a solr war...
[16:35] <mdiggory> and unlike lucene in DSpace, "there can be only one"
[16:35] <mdiggory> unless you do a clustering strategy with solr
[16:35] <mdiggory> which uses rsync to replicate slaves from a master
[16:36] <mdiggory> but thats over the top...
[16:36] <grahamtriggs> mdiggory: I'm thinking I can embed that solr in the main application, and cluster (we use a cluster file system)
[16:36] <mdiggory> you can run solr wherever you want and point at it
[16:36] <mdiggory> I'm not sure if it will work the same way you could do that with DSpace/lucene
[16:37] <mdiggory> solr likes to have but one process operating on the directory at a time (theres a bit of in memory caching going on there)
[16:37] <grahamtriggs> what I've read so far today suggests I could, but that's in the realms of theory
[16:37] <mdiggory> facet warming etc)
[16:38] <mdiggory> Ok, well that would be an interesting and valuable analysis to verify
[16:38] <stuartlewis> lcs: bollini: Could you give us an update on authority control? Is it something that will be finished in time and stable enough for 1.6?
[16:38] <lcs> Got the basics working on XMLUI and JSPUI; choice control, lookup-popup, autocomplete, on Firefox and Safari. Still have to investigate MSIE issues.
[16:38] <lcs> Also have an irresistable improvement (thanks to bollini) to add, and wiki doc update, but expect to be done by next week.
[16:39] <bollini> anyway it looks pretty stable
[16:39] <bollini> we could include in 1.6
[16:39] <lcs> the authority part and data model is stable. the UI may need some shaking out.
[16:40] <stuartlewis> Presumably you'd like to see it in 1.6, rather than put off until 1.7 etc?
[16:40] <stuartlewis> lcs: Is it used in DASH?
[16:40] <lcs> yes, i want to get it into 1.6.
[16:40] <lcs> we're using an early version in production in DASH - mostly what i first checked in.
[16:40] <stuartlewis> I'll try and find time to have a play with it later today. Would anyone have a problem with it going into 1.6?
[16:40] <stuartlewis> It sounds a great addition.
[16:40] <rrodgers> nope
[16:41] <mhwood> I think folks here will be pleased.
[16:41] <mdiggory> the sooner changes get into 1.6 the sooner we can battle through integration issues
[16:41] <stuartlewis> True.
[16:41] <stuartlewis> Should we just get it in there now then?
[16:42] <stuartlewis> And then do the further work in trunk rather than the brach?
[16:42] <mdiggory> always good to fly by the seat of ones pants... ;-)
[16:42] <rrodgers> wait what are we talking about?
[16:42] <lcs> i have one big change left to make (adding collection context to the chioce plugin) and then it would be mostly ready.
[16:43] <stuartlewis> rrodgers: Authority control?
[16:43] <lcs> i was considering doing the merge in the sandbox first, though.
[16:43] <rrodgers> ok, I hoped so
[16:43] <stuartlewis> lcs: Sounds sensible.
[16:43] <bollini> BTW: it should also solve the duplication issues in browse when the same metadata (case insensitive) is used twice or more times
[16:43] <mdiggory> true... I want to understand how much is "addon" and how much is "core"
[16:44] <lcs> it's really just a framework added to core. all the actual choice stuff is added on.
[16:44] <mdiggory> havn't been watching the commits atm, but see them in the changelog
[16:44] <mhwood> If the concept is not controversial, and the implementation is stable enough that there is little chance of having to pull it out again, it's probably time to merge.
[16:45] <bollini> the main change to the core is the addition of a new field/column to the metadatavalue
[16:45] <lcs> ok, it'll take a couple more days for the "implementation stable" part.
[16:45] <lcs> there are also some simple API changes to support the authority and confidence values for each metadata value.
[16:46] <mdiggory> lcs: are there significant database changes?
[16:46] <lcs> added two columns to the metadatavalue table.
[16:46] <bollini> the api changes are mostly (all?) backward compatible
[16:46] <lcs> no conversion is needed since the default values are OK.
[16:47] <mdiggory> ok
[16:48] <lcs> so while we are on this, i have a pile of Javascript that is common between the JSPUI and XMLUI.. wanted to put it in one place and overlay it.
[16:48] <bollini> I have had only issues if you define a metadata as "authority control required" and you have invalid data already in place
[16:48] <lcs> what is the best way to do this in the maven structure -- add a "webapp" subdir to dspace-api, or create a new project for it?
[16:49] <bollini> new project, we can't exclude that in the next future we could have a 3rd UI that don't need this stuff
[16:51] <mdiggory> hmm...
[16:52] <lcs> i was also tempted to put it in a new subproject under dspace-xmlui, and overlay that on both the xmlui and jspui projects.. but this is a job for a maven maven
[16:52] <mdiggory> I do not want us to go down the overlay road too often for smaller cases such as common resources
[16:53] <grahamtriggs> can we use the unpack dependency here?
[16:53] <lcs> if there's a better way to share common resources in webapps I'll be happy to do that. i just don't want the same code in two places.
[16:53] <mdiggory> I would just replicate the resources in xmlui-webapp and jspui-webapp
[16:54] <lcs> some of it is my code, which will be subject to updates, and the rest is a patched version of scriptaculous. copies _will_ drift.
[16:55] <mdiggory> well, with qualification here....is the pile of javascript referenced in dspace-xmlui-webapp and dspace-jspui-webapp directly or are you doing another maven project for those additions to the codebase...
[16:56] <lcs> right now it's directly in the webapp, and it needs to end up in the WAR, but i'm amenable to a separate project for the shared JS code.
[16:57] <mdiggory> I'm concerned about setting a precident
[16:57] <rrodgers> Sorry, but I've got to run soon - are we done with committer agenda?
[16:57] <bollini> a little community admin update
[16:57] <mdiggory> I'd just replicate it in both projects and leave a README to keep both uptodate if you start making changes
[16:58] <stuartlewis> bollini: Yes - that would be good.
[16:58] <bollini> ok, I have completed the api changes and the jspui stuff
[16:58] <mdiggory> If we start to get much more replication than this... then revisit the common project strategy
[16:59] <bollini> if you have read my last email on the devel list, I have choice the 2nd option - use deferrable strategy with few foreign key constraints
[16:59] <lcs> mdiggory: i really don't want copies, nobody looks at READMEs.. but, later.
[17:00] <bollini> the api is full aware of the "authorize system configuration" so the xmlui is already in place but we want hide inappropriate buttons
[17:00] <mdiggory> I'm concerned about overlaying being used for anything other than end user customization in the modules dir
[17:00] <mdiggory> it is an expensive part of the build process
[17:01] <mdiggory> and IDE tools are not so good at coping with overlays...
[17:01] <stuartlewis> bollini: Is that something you can get done in time for 1.6?
[17:01] <bollini> mdiggory: lcs: we can try to keep two separate copies of the js and re-evaluate this decision if it is too expensive
[17:02] <bollini> stuartlewis: It will be ready for 1.6
[17:02] <bollini> I will post a first patch (api + jspui) before the end of the week
[17:03] <stuartlewis> Excellent :)
[17:03] <stuartlewis> 1.6 keeps getting better and better. There will be a lot of new big features in it.
[17:03] <lcs> is anyone doing the xmlui work on that, or did i just volunteer?
[17:03] <rrodgers> Unless there are objections, in addition to Embargo (checked in), I want to commit ItemUpdater, and OpenSearch within the week
[17:03] <bollini> if you all agree I would commit the api stuff as soon as possible so to have enougth time to test it in an integrate enviroments
[17:04] <stuartlewis> rrodgers: +1
[17:04] <mhwood> rrodgers, bollini: no objections here.
[17:05] <bollini> OpenSearch +1 ItemUpdater 0 I don't know what it is
[17:05] <stuartlewis> ItemUpdater is a command line tool to bulk update items
[17:05] <rrodgers> bollini: It is a companion to ItemImport and Export - where you can update metdata fields
[17:06] <rrodgers> no api or schema changes
[17:07] <bollini> nice :-)
[17:07] <lcs> ++(rrodgers)
[17:07] <stuartlewis> Any other business before we close the meeting?
[17:08] <rrodgers> OK - thanks all - must go
[17:09] * rrodgers (n=rrodgers@pool-173-76-16-252.bstnma.fios.verizon.net) Quit ()
[17:09] <grahamtriggs> lcs: increment rrodgers?
[17:09] <mhwood> Me too. Thanks all!
[17:09] <lcs> grahamtriggs: +1 gets boring
[17:09] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:10] <bollini> bye all
[17:10] * bollini (n=chatzill@87.10.22.119) Quit ("ChatZilla 0.9.85 [Firefox 3.0.14/2009082707]")
[17:10] <grahamtriggs> how about lcs&1
[17:25] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) Quit ()
[17:35] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) Quit ("Leaving.")
[18:06] <stuartlewis> lcs: Are you happy if I tinker with the authority control branch? (e.g. add the postgres database schema update)
[18:07] <lcs> sure, that would be great! i'll be checking in some changes soon too.. just figured out how to share JS code without the dreaded overlays.
[18:08] <stuartlewis> Tried editing on the wiki too, but the wiki is bust :(
[18:08] <stuartlewis> "from within function "MediaWikiBagOStuff::_doinsert". MySQL returned error "1114: The table 'dspace_objectcache' is full (libdb.mit.edu)"."
[18:11] <lcs> d'oh! sorry, i am no longer in a position to go to the next cube and kick someone.
[18:11] <stuartlewis> Do you want me to merge the file too, e.g. the 15->16 postgres upgrade, pull in the changes to that file that are in trunk to make your life easier when you do the full merge?
[18:13] <lcs> sure, that would be great, thanks!
[18:14] <lcs> obtw, i entered a ticket in MIT Libraries' tracker about the wiki.
[18:14] <stuartlewis> I'll do it as soon as firefox stops being an idiot and crashing on me.
[18:14] <stuartlewis> Ah - so did I :)
[18:28] <stuartlewis> lcs: I've got the authority control branch up and running. Is there a dummy's guide somewhere for how to enable it on fields?
[18:29] <stuartlewis> Actually - found it in the wiki: 'Configuring and Customizing Choices and Authority'. WIll have a play.
[18:30] <lcs> not yet.. let me dig out some sample configs.
[18:30] <lcs> (that's what i was planning to put on the wiki..)
[18:32] <lcs> first you have to uncomment the property "plugin.named.org.dspace.content.authority.ChoiceAuthority"
[18:32] <lcs> and then uncomment the "lcname.*" and "sherpa.*" properties for those plugins.
[18:33] <stuartlewis> Was hoping to try the dc.realtion.journal -> sherpa authority
[18:33] <lcs> oh, sure, that'd be:
[18:33] <lcs> choices.plugin.dc.relation.journal = SRJournalTitle
[18:34] <lcs> choices.presentation.dc.relation.journal = suggest
[18:34] <lcs> (or lookup if you prefer)
[18:34] <lcs> you can add authority control with
[18:34] <lcs> authority.controlled.dc.relation.journal = true
[18:34] <stuartlewis> Lookup would be good.
[18:35] <lcs> (i actually have a wacky XSL setup that uses that plugin and shoves teh authority value into a separate metadata field for ISSN.)
[18:36] <lcs> The Sherpa/ROMeO web service is pretty crude. it only ever returns 50 matches, no option to get more.
[18:36] <stuartlewis> It also goes offline from time to time I think when their upstream data provider goes down.
[18:38] <stuartlewis> dspace.cfg suggests that the AJAX stuff only works in JSPUI. Is that true?
[18:38] <lcs> if you have a lot of journal listings in your local library catalog it might be possible to use SR/W queries instead. the LCName example choice plugin is a quick-and-dirty SR/W client.
[18:38] <stuartlewis> ## AJAX Choise Authority Response generator JSPUI only ##
[18:38] <lcs> oh, no, it works in XMLUI. Those particular plugins are only used in JSPUI. Andrea added that.
[18:38] <stuartlewis> Great :)
[18:39] <lcs> those are actually to get the AJAX response out of JSPUI. XMLUI does it with cocoon.
[18:39] <stuartlewis> Do I need to add anything to input-forms.xml, or will it just work?
[18:39] <lcs> no changes to input-forms.
[18:43] <stuartlewis> Excellent - got it working. Thanks :)
[18:43] <stuartlewis> Do the sherpa lookups get cached (bit slow otherwise)
[18:44] <lcs> it seemed fast enough from here, but that could be a good idea. perhaps easiest to set up a proxy server and just change the configured URL.
[18:45] <lcs> i didn't implement any caching. the sherpa plugin was just a quick example, but improvements are always welcome.
[18:45] <stuartlewis> Yeah - NZ is on the end of a bit of wet string when it comes to connectivity :(
[18:46] <stuartlewis> I might look into making a local caching server, and one that can return > 50 records at a time.
[18:46] <stuartlewis> Journal title lookup isn't working - not sure what I've done wrong. "Failed to load choice data: HTTP error response"
[18:46] <lcs> i didn't even look into it too deeply -- is their whole database available for download? that'd be handy.
[18:47] <lcs> ah, the details should be in the log
[18:48] <stuartlewis> 2009-09-24 10:48:06,976 WARN org.dspace.app.xmlui.cocoon.DSpaceI18NTransformer @ Translation not found for attribute value in element <input>
[18:48] <stuartlewis> 2009-09-24 10:48:06,985 WARN org.dspace.app.xmlui.cocoon.DSpaceI18NTransformer @ Translation not found for attribute title in element <input>
[18:48] <stuartlewis> 2009-09-24 10:48:07,347 WARN org.dspace.app.xmlui.cocoon.AJAXMenuGenerator @ AJAX menu generator: field=dc_relation_journal, query=, start=0, limit=0, format=select
[18:48] <stuartlewis> 2009-09-24 10:48:07,347 WARN org.dspace.app.xmlui.cocoon.AJAXMenuGenerator @ Got locale =
[18:51] <lcs> hmm, those last couple of WARNs should be DEBUG. you can just give it the /choice.. AJAX request
[18:53] <stuartlewis> Sorry - what do you mean by give it the /choice... AJAX request?
[18:53] <lcs> trying to dig up an example.. mysite/xmlui/choices/dc_relation_journal?value=foo
[18:54] <lcs> that's the ajax query the lookup page makes to fill in its selector.
[18:56] <stuartlewis> Caused by: java.lang.NullPointerException
[18:56] <stuartlewis> at org.dspace.app.xmlui.cocoon.AJAXMenuGenerator.generate(AJAXMenuGenerator.java:124)
[18:56] <stuartlewis> When I try: http://localhost:8080/xmlui/choices/dc_relation_journal?value=Information
[18:57] <stuartlewis> Which is a log line: log.warn("Result count = "+result.values.length+", default="+result.defaultSelected);
[18:59] <lcs> that's weird, it was working yesterday.
[18:59] <stuartlewis> So 'Choices result = ChoiceAuthorityManager.getManager().getMatches(field, query, start, limit, locale)' seems to be returning null.
[19:00] <lcs> yeah, that's the romeo plugin. it shouldn't be.
[19:02] <stuartlewis> WARN org.dspace.app.xmlui.cocoon.AJAXMenuGenerator @ AJAX menu generator: field=dc_relation_journal, query=, start=, limit=, format=
[19:02] <stuartlewis> Should the query have got passed through?
[19:02] <lcs> oh, duh, the parameter name is "query".. this works: i/choices/dc_relation_uri?query=food
[19:03] <stuartlewis> That's looking better... but still sloooooow
[19:03] <stuartlewis> 20 seconds later, I now have an xml page of <choices>
[19:03] <lcs> That must be the wet string. it's fast here.
[19:04] <stuartlewis> I think I see the problem.... do you have to enter a value before you hit 'Lookup'?
[19:05] <lcs> it depends on the plugin, for sherpa, yes, some others work with no value.
[19:05] <stuartlewis> I was trying it with no value
[19:05] <lcs> i have to work out the rules for plugin writers.
[19:06] <lcs> i've usually used that one with the suggest presentaiton mode, where it won't get called until there is a value.
[19:07] <stuartlewis> It works now :) Thanks
[19:07] <lcs> thanks for teh testing! i'll look into that NPE
[19:10] <stuartlewis> No prob. People are going to love this - it is nice.
[19:10] <lcs> thanks!
[19:11] <stuartlewis> Can the ajax suggests work on the field itself (in otherwords when entering an author, can it provide suggestions from existing values for authors already in metadatavalue )
[19:12] <stuartlewis> So can DSpace metadata act as an authority to itself?
[19:12] <lcs> that's all up to the plugin implementation -- it could certainly do that.
[19:15] <stuartlewis> That would be a nice out-of-the-box plugin to have. Presumably would be hard for author though due to the split nature of the two input boxes.
[19:17] <lcs> I just treat it as a single string - combine the names with DCPersonName when passing into the choice machinery, and split it to put values back in the boxes.
[19:17] <stuartlewis> You use it as a lookup rather than suggest?
[19:18] <lcs> oh, yeah. i guess suggest could be made to work but it would be madness.
[19:19] <lcs> for DASH we only need to identify Harvard-affiliated authors so i do an LDAP query.
[19:20] <stuartlewis> Do you also store some sort of internal ID to make the local authors lookup work (in the end user UI)
[19:20] <stuartlewis> (We noticed you've hidden the 'show full record' page, so we couldn't see how you did it! :) )
[19:21] <lcs> heh, you ought to be able to figure out how to get the full record page, i only hid the link. and local authors have an authority value, an obfuscated hash of an internal ID.
[19:23] <stuartlewis> Oh yeah! ?show=full
[19:26] <lcs> The big deal was making authors link to these Profile pages.. it only works for one guy right now since they haven't populated the rest, but if you go to http://dash.harvard.edu/handle/1/2031671, click on "Weber, Griffin"
[19:26] <stuartlewis> <dim:field authority="1853a247003a276919d75fde55f5e202" element="contributor" confidence="6" mdschema="dc" qualifier="author">Snedeker, Jesse</dim:field>
[19:27] <stuartlewis> Nice!
[19:40] * ksclarke (n=kevin@adsl-1-145-78.clt.bellsouth.net) has joined #duraspace
[20:21] * bradmc_ (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) has joined #duraspace
[20:30] * bradmc (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) Quit (Read error: 110 (Connection timed out))
[20:30] * bradmc_ is now known as bradmc
[22:04] * mdiggory (n=mdiggory@nmd.sbx10180.carlsca.wayport.net) Quit (Read error: 113 (No route to host))
[22:10] * lcs (n=lcs@serenity.hul.harvard.edu) has left #duraspace
[22:36] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[22:56] * ksclarke (n=kevin@adsl-1-145-78.clt.bellsouth.net) Quit ("Leaving.")
[23:25] * bradmc_ (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) has joined #duraspace
[23:25] * bradmc (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) Quit (Read error: 104 (Connection reset by peer))
[23:25] * bradmc_ is now known as bradmc
[23:28] * bradmc_ (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) has joined #duraspace
[23:28] * bradmc (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) Quit (Read error: 104 (Connection reset by peer))
[23:30] * bradmc_ is now known as bradmc
[23:33] * bradmc (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) Quit (Read error: 104 (Connection reset by peer))
[23:33] * bradmc_ (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) has joined #duraspace
[23:33] * bradmc_ is now known as bradmc
[23:56] * bradmc (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) Quit (Read error: 104 (Connection reset by peer))
[23:56] * bradmc_ (n=bradmc@c-65-96-241-42.hsd1.ma.comcast.net) has joined #duraspace
[23:56] * bradmc_ is now known as bradmc
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.