Timestamps are in GMT/BST.
[1:08] * krnl_ (i=krnl_@193.219.158.144) has joined #duraspace
[1:10] * krnl__ (i=krnl_@193.219.158.144) Quit (Read error: 145 (Connection timed out))
[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:07] * ClaudiaJuergen (n=Miranda@129.217.135.102) has joined #duraspace
[5:51] * grahamtriggs (n=trig01@80.169.130.178) has joined #duraspace
[5:51] * grahamtriggs (n=trig01@80.169.130.178) Quit (Client Quit)
[6:21] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit ()
[7:20] * grahamtriggs (n=trig01@80.169.130.178) has joined #duraspace
[8:09] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:16] * justben (n=ben@hypatia.library.emory.edu) has joined #duraspace
[9:25] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) has joined #duraspace
[11:54] * jat_ysu (n=jeffreyt@maag127.maag.ysu.edu) has joined #duraspace
[12:12] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) has joined #duraspace
[12:33] * ClaudiaJuergen (n=Miranda@129.217.135.102) Quit ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
[13:10] * grahamtriggs (n=trig01@80.169.130.178) has left #duraspace
[15:44] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace
[15:58] * lcs (n=lcs@serenity.hul.harvard.edu) has joined #duraspace
[16:00] <stuartlewis> DSpace meeting due to start in 2 mins - Brad is on the road today, so any volunteers to drive? If not, I can do so.
[16:00] <jat_ysu> exit
[16:01] <kshepherd> stuartlewis: you've scared jeff off already ;)
[16:01] <jat_ysu> LOL..sorry
[16:01] <jat_ysu> I was at my unix prompt
[16:01] <kshepherd> heh yeah guessed as much
[16:02] <stuartlewis> OK - topics for meeting?
[16:02] <jat_ysu> I don't drive...it's too haaard...
[16:02] <jat_ysu> Documentation questions
[16:03] <kshepherd> 1.6 stats update + plan for further UI work, if the right people show up?
[16:03] <jat_ysu> yes.. that impacts my questions too
[16:03] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[16:03] * rrodgers (n=rrodgers@dhcp-18-111-1-240.dyn.mit.edu) has joined #duraspace
[16:04] <lcs> looks like the right people just showed up.
[16:05] <kshepherd> :)
[16:05] <stuartlewis> :)
[16:05] <mdiggory> oh wait... next time I join under an alias ;-)
[16:05] <kshepherd> heh
[16:05] <stuartlewis> OK - shall we start with an update on stats, then run through documentation issues, then conclude with AOB?
[16:05] <jat_ysu> <==on the run in 30 min.
[16:05] <mhwood> Topics? Jason Fowler's dspace-tech question about HTML5
[16:06] <stuartlewis> OK - we'll add that to AOB
[16:06] <lcs> i have an improvement to RSS feeds to discuss if there's time
[16:06] <stuartlewis> Mark: Can you give us an update on stats? An ETA for completion, and if we can help out at all?
[16:07] <mdiggory> sorry, phone call, can you rearange the order slightly?
[16:07] <stuartlewis> OK - doc questions?
[16:07] <mhwood> Rough documentation? (what goes where and gets configured how)
[16:08] <jat_ysu> Installation for 1.6 and more important updating to 1.6
[16:08] <jat_ysu> Other than Oracle scrips I am aware of...will solr be a separate install?
[16:08] <rrodgers> true - has anyone tackled update scripts, etc?
[16:08] <jat_ysu> yes..postgresq scripts too...Larry did some work, right?
[16:09] <lcs> i did a bit of tidying and commenting on the Oracle update but it still needs some messy manual steps. i can help doc and test.
[16:09] <mhwood> Do we have a firm idea of what schema changes will go in?
[16:09] * justben (n=ben@hypatia.library.emory.edu) has left #duraspace
[16:09] <jat_ysu> I'd like to write some of it now, but I can hold off until last minute and we do some testing.
[16:10] <jat_ysu> messy manual steps? **shudders**
[16:10] <stuartlewis> solr is just another webapp like any other. Deployed by copying it to [tomcat]/webapps/
[16:10] <lcs> the change to explicitly naming the constraints is "hard" in Oracle.
[16:10] <jat_ysu> The current install has been revised on my server. Please look it over.
[16:10] <jat_ysu> Will solr be integrated into the dspace mvn / ant process?
[16:11] <stuartlewis> jat_ysu: Looking good - I like the addition of the little icons etc - looks a lot more professional :)
[16:11] <jat_ysu> I added the different types of unpacking the software....there are three....
[16:11] <stuartlewis> jat_ysu: Yes - solr just pops out the end of the mvn/ant process in the [dspace]/webapps directory like jspui / xmlui / oai etc.
[16:11] <jat_ysu> Perfect.
[16:12] <lcs> jat_ysu: ch03.html still has the line "Go to [dspace-source]/dspace/etc/oracle and copy the contents to their parent directory, overwriting the versions in the parent" that i removed in the svn version of the xml source, do you still have to merge that?
[16:12] <jat_ysu> Then install is really good to go. It will be UPDATE that will need the most amount of work.
[16:12] <jat_ysu> lcs: That was my oops....
[16:12] <jat_ysu> Send me an email to remind me to remove it. I might have clobbered your edit in SVN.
[16:12] <lcs> ok, it's all in changeset 4427 in svn
[16:13] <jat_ysu> oky
[16:13] <jat_ysu> So we have update to deal with.
[16:13] <lcs> you can just get the changes with svn diff and re-patch your working copies.
[16:13] <jat_ysu> I want one other issue that I need your thinking caps for
[16:14] <stuartlewis> The majority of update can be worked out by comparing dspace.cfg from 1.5.2 and 1.6, and the same for config directory contents.
[16:14] <stuartlewis> What is our recommendation these days? That users start with a new dspace.cfg and put their old values in it, or that they upgrade their current dspace.cfg?
[16:14] <jat_ysu> Yes, you're right, and I'm keeping a list of those as I edit the configuration.xml file
[16:15] <jat_ysu> IMHO I've always edited my existing dspace.cfg except when I migrated servers.
[16:15] <mdiggory> ok, I am back now
[16:15] <jat_ysu> I'd like to separate out from the Application Layer chapter, all of the "stuff: from section 9.3 into their own chapter. So what do you call all the indiviation parts that run on command?
[16:15] <mhwood> I believe the latest recommendation was to import old values into a clean new config.
[16:15] <lcs> I suspect it would be easier for most admins to see a breakdown of what's changed in the config properties.. they may see it as black magic and not want to build a new one from scratch.
[16:15] <jat_ysu> mhwood; I did that once, and it clobbered my existing stuff..I mean clobbered.
[16:16] <mdiggory> yes, solr is both created as a solr directory with configuration by the ant install and the war is packaged and deployed into the webapps directory
[16:16] <jat_ysu> mdiggory: great. I don't have to worry about update then.
[16:17] <jat_ysu> Do you have any preliminary documentation on solr that I should start to work into the documentation yet?
[16:17] <mdiggory> well, it would be good to probably add such details to the installation / upgrade documentation which refers to directories that are created
[16:17] <stuartlewis> I a way solr is self contained, so doesn't need much in the way of documentation. It comes preconfigured etc.
[16:17] <stuartlewis> In*
[16:18] <jat_ysu> Okay......could you send those to me when you are ready?
[16:18] <mdiggory> I think we will eventually want to document details such as EventServices and dspace-services and how to configure them via the spring applicationContext files
[16:19] <jat_ysu> Are you wanting them included in the final 1.6 documentation or in a later version?
[16:19] <mhwood> Yes, please.
[16:20] <mdiggory> jat_ysu: do you have a format you would prefer such documentation to be in? (other than hand edited docbook shudder)
[16:20] <jat_ysu> Either word, wordperfect or text is fine.
[16:20] <mdiggory> ok... good
[16:20] <jat_ysu> Word will allow you to bold or italicize something you wish to be of note.
[16:20] <mdiggory> I'll get out my ancient copy of Workperfect ;-)
[16:21] <jat_ysu> Dont make fun of me...I'm a WP fan.
[16:21] <mdiggory> I didn't even realize it was still around ;-)
[16:21] <jat_ysu> But then again, I'm starting to write other things in docbook now.
[16:21] <mdiggory> AGH!
[16:21] <jat_ysu> Great I've got Install/Update and solr answers.
[16:22] <jat_ysu> One more thing and I'm on the run.
[16:23] <jat_ysu> Would anyone have a problem with pulling all the "stuff" from section 9.3+ and making its own chapter called "Application Programs"? It would show how to do batch import/export, etc. how to set them up. All the details of how some component works.
[16:23] <stuartlewis> No - sounds fine.
[16:23] <jat_ysu> good. Done.
[16:23] <rrodgers> fine by me
[16:23] <mhwood> Sounds like good organization.
[16:23] <kshepherd> yep sounds good
[16:23] <jat_ysu> Very good all. I've got to run and see my personal trainer from hell. Wish I could stay.
[16:24] <mhwood> Thanks!
[16:24] <rrodgers> Thanks jat_ysu
[16:24] <mdiggory> I think there should be a strong separation btween "application CLI" and te rest of the doc
[16:24] <lcs> thanks!
[16:24] <jat_ysu> mdiggory..strong as how do you mean?
[16:25] * mdiggory thinks "circular file"... but says chapter is good
[16:25] <mdiggory> chapter is good
[16:25] <jat_ysu> okay.
[16:25] <mdiggory> yes, many many thanks jat_ysu
[16:26] <jat_ysu> don't thank...buy Alcohol.
[16:26] <jat_ysu> LOL
[16:26] * jat_ysu (n=jeffreyt@maag127.maag.ysu.edu) has left #duraspace
[16:27] <mhwood> [crickets]
[16:27] <kshepherd> *tumbleweed*
[16:27] <lcs> re solr, are there any differences on an Oracle site, or is it important to test on one?
[16:27] * mdiggory too many chat windows open at once...
[16:27] <stuartlewis> OK: mdiggory: Can you give us an update on stats? An ETA for completion, and if we can help out at all?
[16:27] * justben (n=ben@hypatia.library.emory.edu) has joined #duraspace
[16:27] <mdiggory> lcs: no, it doesn't deal at all with the db
[16:28] * justben (n=ben@hypatia.library.emory.edu) has left #duraspace
[16:28] <mdiggory> Ok, well you pinged me eariler about the idea of providing presentation first for the XMLUI in 1.6.0 and then later for JSPUI in 1.6.1 how do others feel about that?
[16:28] <lcs> mdiggory: good, i don't have to worry about testing it explicitly here.
[16:29] <mdiggory> right now the implementation in XMLUI of the presentation is an aspect included into those Community, Collection and Item views.
[16:29] <kshepherd> i've been testing out the 'views' surfacing in XMLUI
[16:29] <mhwood> Selfishly: if one has to slip, let it be JSP. But I dunno how the rest of the Installed Base will see that.
[16:29] <rrodgers> I have mixed feelings - officially I thought 1.6 sought UI parity
[16:29] <mdiggory> At DSUG we chatted about if statistics should be on a separate page.
[16:30] <kshepherd> looks good... was wondering if i can help work on other events, on JSPUI etc
[16:30] <stuartlewis> Yes - if tie becomes an issue, was can only release the 'viewing' of stats in xmlui, but have jspui and xmlui recording stats in solr. We can then release viewing of stats in jspui in 1.6.1. Thoughts?
[16:30] <stuartlewis> time*
[16:30] <kshepherd> mdiggory: some people may expect some generic 'reports' on seperate pages
[16:30] <stuartlewis> mdiggory
[16:30] <stuartlewis> ;
[16:31] <mdiggory> kshepherd: if you want to tag team on the views in JSPUI and XMLUI, I would find that very good
[16:31] <stuartlewis> mdiggory: Do you reckon a few of us could gang together and get jspui done quite quickly?
[16:31] <kshepherd> ok, cool
[16:31] <mhwood> That's some of the discussion I could never get started: what do we do with all the numbers?
[16:31] <mdiggory> stuartlewis: I suspect that we could
[16:31] <stuartlewis> mdiggory: What is the ETA on xmlui stats?
[16:32] <stuartlewis> mdiggory: Is the colelctioning part of the stats completed now, is it just UI work to be done, or is there more work in collecting stats that needs doing?
[16:32] <stuartlewis> collecting*
[16:32] <mdiggory> depends on how adventurous we get. The current strategy is hardcoded in the aspect transformer.
[16:33] * kshepherd needs to take a closer look under the hood
[16:33] <mdiggory> I had ideas that the StatisticsDisplays could be configurable in the spring applicatioContext... but that is not yet implmented
[16:33] <stuartlewis> Not too adventurous - we're getting short on time
[16:33] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) Quit ()
[16:33] <mdiggory> if time is an issue, this can always be an enhancement for version 1.6.1
[16:34] <mhwood> Maybe defer to a broader "making more use of Spring" effort in 1.6.x?
[16:34] <mdiggory> but ultimately the JSPUI detail is possibly more critical having a team discussion and attack on it would more than likely get things done opn both JSPUI and XMLUI
[16:35] <stuartlewis> Or jump to a 1.7 once we clear up any issues with a 1.6.1? Try to stay a bit more agile?
[16:36] <mdiggory> the work left in XMLUI is (1) move statistics to separate page (2) externalize/internationalize labels (3) decide which reports are relevant important
[16:36] <grahamtriggs> agile isn't about doing things faster :)
[16:36] <mdiggory> in JSPUI we need (1) some transformation of the StatistiDisplay data model to html
[16:37] <mdiggory> (2) similar externalization
[16:37] <mdiggory> its about getting out of the way faster (ducks)
[16:38] <stuartlewis> grahamtriggs: No, but by moving to a 1.7, we can make more architectural changes without having to wait a whole year to make them.
[16:38] <mhwood> I think we need more input from the broader community as to what reports would be relevant. Talk about the raw capabilities of the new stuff and try to find out what people are thinking when they say, "statistics."
[16:38] <kshepherd> ok, i'll start having a look at the JSPUI side soon
[16:39] <mdiggory> mhwood: I agree... and that will come as configuration is made more flexible as well
[16:39] <stuartlewis> Yeah - too late for too much consultation now. Get some basic stats out, then improve them based on feedback in subsequent versions.
[16:39] <kshepherd> mhwood: yeah, that's kinda been the problem from the beginning ;) but in some ways, people may not know what they want until they see an example of what is possible in front of them.. perhaps that is what this release can do
[16:39] <grahamtriggs> I agree we need to make some big changes quickly after 1.6, rather than trickle out bug fixes. But that's a matter best left until after we've got 1.6 out of the way before discussing (don't want/need to take energy away from 1.6)
[16:39] <mdiggory> On last other item has to do with trolling the logs and populaitng the Solr Logs with past UsageEvents.
[16:40] <kshepherd> ah yes
[16:40] <mdiggory> This I've not tried yet.
[16:40] <stuartlewis> kshpepherd: OK - I'll join in with you (jspui stats). Any other volunteers?
[16:40] <kshepherd> i thought a dspace log -> eventusage xml converter would be handy
[16:40] <kshepherd> or something similar
[16:40] <mhwood> It will be essential, I think, for sites (raises hand) that already have statistics by Other Means.
[16:40] <lcs> it would be good to have an API to add historical events from random soruces (like the logs i've been keeping)
[16:41] <mhwood> We don't want to explain why our counters ran backward.
[16:41] <kshepherd> indeed
[16:41] <mdiggory> lcs (random sources) ?
[16:41] <kshepherd> and i don't think we've been able to address the 'retroactive handling of spider IPs we discover later' issue in these stats
[16:41] <stuartlewis> mdiggory: Is this something you need to do, or could it be done by anyone?
[16:41] <mhwood> Spiders, ugh, exactly.
[16:41] <kshepherd> which means if a significant % of views are discovered to be spiders, people may want to reimport from logs again
[16:41] <lcs> random sources == site-specific or custom stand-in for logging
[16:42] <mdiggory> stuartlewis: I envision it as the following (1) get the code out of the legacy statistics / reporting implementation that trolls the dspace log
[16:43] <mdiggory> (2) wire it into the SolrLogger instead to issue writes tot he Solr server.
[16:43] <mdiggory> but (2) needs to be done correctly to be effient
[16:43] <mdiggory> efficient
[16:44] <mdiggory> I.E. multiple solr documents appended in one request
[16:44] <stuartlewis> OK - I'm happy to look at that if you want?
[16:45] <mdiggory> that would be helpful, perhaps we can plan out a secondary meeting in IRC to dig through these details/
[16:45] <stuartlewis> OK - we can chat about that and jspui later today if that suits?
[16:46] <stuartlewis> Can we give ourselves a target for stats completion? 2 weeks?
[16:46] <mdiggory> yes, after I've eaten something...
[16:47] <mdiggory> so, we never did an alpha release... that is also something to factor in...
[16:47] <rrodgers> Holiday season will become an issue for alpha/beta public stuff...
[16:48] <mdiggory> true... but at least its not a "conference deadline" that would be pushing us....
[16:48] <stuartlewis> Testathon at mid Nov, release end nov to mid dec?
[16:49] <mdiggory> I really think we need to start doing something automated for testahon that will make things easier on testers.
[16:49] <stuartlewis> We can celebrate release with a mince pie and turkey dinner!
[16:49] <rrodgers> stuartlewis: no beta?
[16:50] <lcs> mdiggory: I think that's called a test suite :-)
[16:50] <mdiggory> :-) why yes, it is ;-)
[16:51] <stuartlewis> Depends what the testaton throws up I suppose, and if any bug fixes will require a big regression test. Getting people to participate in testathons hasn't been so successful recently :(
[16:51] <mdiggory> I was just thinking if someone could setup a JMeter test script or something that could be pointed at a test site and run
[16:51] <stuartlewis> Our developer is writing some JMeter scripts at the moment to try and help us find db connection leaks in xmlui.
[16:51] <mhwood> So, who in the community is good at building tests?
[16:51] <rrodgers> we have done some Selenium work along those lines..
[16:51] <mdiggory> though I suspect there are some features of sequences that may or may not make tht more difficult than just recording clicks
[16:51] <stuartlewis> Shall we put a call out?
[16:52] <mdiggory> stuartlewis: sounds like your "developer" might be an ideal candidate
[16:53] <stuartlewis> I'll ask - not sure if the scripts she is writing (to just hammer it hard in certain places) will provide the coverage we're after. But I'll ask.
[16:53] <mdiggory> Selenium sounds interesting as well
[16:54] <mhwood> Maybe several groups can test different aspects, and we can integrate on one platform after there's more experience?
[16:54] <mdiggory> An initial starting point would be more important than full test coverage.... having a starting point means others can contribute paths to get fuller test coverage
[16:55] <mhwood> Yes
[16:55] <mdiggory> it would be an excellent community exercise.
[16:55] <mdiggory> Contribute to testing to do way with human driven testathons...
[16:56] <stuartlewis> Is there anyone who fancies driving this, and gathering effort from the community?
[16:56] <mdiggory> use selenium or JMeter to generate test paths and contribute them to a JIRA ticket
[16:56] <rrodgers> That's a good start
[16:57] <mdiggory> Someone create a category in JIRA for testing?
[16:58] <mdiggory> stuartlewis: can you get your developer to start pushing anything they are doing into a JIRA ticket? They don't ahve to drive things... just make the work you already have them doing transparent
[16:58] <stuartlewis> Ok - I'll ask
[16:59] <mdiggory> rrodgers: do you already have any Selenium tests that can be added?
[16:59] <rrodgers> mdiggory: I think so, but I've got to dust them off...
[17:01] <rrodgers> In the sense of requalifying them for 1.6
[17:01] <mdiggory> sounds like a start. rather than assigning czar status to someone, maybe lets just see if we can get a few examples up in JIRA to talk about next week?
[17:01] <stuartlewis> OK - sounds good
[17:01] <stuartlewis> How will we manage them in JIRA?
[17:02] <stuartlewis> Will the issue stay open for ever?
[17:02] <stuartlewis> Would a wiki page be better?
[17:02] <grahamtriggs> sounds like you are confusing it with the sourceforge tracker :)
[17:03] <mhwood> Maybe close the issue when a good set is worked out, and let further contributions be individual?
[17:03] <lcs> it would be easier to find on the wiki. at the very least there oughtt o be a wiki page pointing to jira
[17:03] <mdiggory> No, the issue should be to create a test suite space for 1.6, and the test would be committed to trunk once we felt we have some agreement for moving forward
[17:04] <mdiggory> if that conflates release and testing too closely, then place them in modules or something
[17:04] <stuartlewis> Will we have time for that in 1.6? Maybe better to keep it informal in the wiki for this release?
[17:04] <stuartlewis> + we know people interact with the wiki better at present than with JIRA
[17:04] <mdiggory> whatever works
[17:04] <mhwood> It sounds like 1.6.x will be an environment for test development?
[17:05] <stuartlewis> OK - we've gone over the hour now.
[17:05] <stuartlewis> Any other topics for discussion?
[17:05] <lcs> how slushy is the code freeze?
[17:05] <mhwood> HTML5? Especially the audio/video stuff. We need something in that area anyway.
[17:05] <lcs> I have a patch that merges all the code to generate RSS/ATOM feeds from OpenSearch and the browse-type feeds and adds configurable addition of explicit DC elements in feed items
[17:05] <stuartlewis> lcs: Depends ;) What do you want to add?
[17:06] <stuartlewis> lcs: Is it in JIRA to look at?
[17:06] <mdiggory> hm... can we review ti a bit first?
[17:07] <lcs> i'll put it up, haven't finished the JSPUI part but i'll hold off for now (ran out of time anyway)
[17:08] <stuartlewis> HTML5: Open a JIRA issue to allow for discussion?
[17:08] <rrodgers> Why not?
[17:09] <lcs> html5: also post to dspace-tech at least for wider exposure, directing them to JIRA
[17:10] <mhwood> Yes
[17:10] <stuartlewis> rrodgers: Why not what?
[17:10] <rrodgers> stuartlewis: sorry I meant +1 JIRA
[17:10] <stuartlewis> OK. I'll open that after the meeting then, and post to dspace-dev/-tech
[17:11] <stuartlewis> Any other business?
[17:12] <rrodgers> I'm looking for volunteers
[17:12] <rrodgers> to help test a Google SEO
[17:13] <rrodgers> actually Google Scholar
[17:13] <stuartlewis> What does it involve?
[17:13] <lcs> rrodgers: i'd like to know more at least
[17:14] <rrodgers> They reached out to us to start using a 'microformat' in HTML head tags
[17:14] <mdiggory> anything that improves the current html head abuse going on would be a plus
[17:14] <rrodgers> They appear in simple & fill Item page
[17:14] <rrodgers> full -> fill
[17:15] <grahamtriggs> slushy code freezes - I had a request to integrate the (optional) submission step so that users could enter a PubMed ID and have the metadata prefilled
[17:15] <stuartlewis> grahamtriggs: Sounds good
[17:15] <rrodgers> Anyway, we want to validate that we have the mapping logic flexible enough for different colleciton types
[17:15] <mdiggory> grahamtriggs: if its just an option... that seems like a good patch
[17:16] <lcs> grahamtriggs: is that a whole step or just a new data type?
[17:16] <grahamtriggs> whole step
[17:17] <stuartlewis> Any other business? Or shall we close the meeting now?
[17:17] <stuartlewis> Feel feee to continue informally afterwards
[17:17] <mhwood> I need to run now either way. Thanks all.
[17:17] <stuartlewis> OK - meeting over. As ever, thank you for your time. Same time, same place, same channel, next week! Bye :)
[17:18] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:19] <grahamtriggs> hmmm.... shouldn't we move it to 9pm GMT next week?
[17:19] <rrodgers> Must go also - thanks all and let me know if you want the Google patch (XMLUI only ATM)
[17:19] * rrodgers (n=rrodgers@dhcp-18-111-1-240.dyn.mit.edu) Quit ()
[17:19] <stuartlewis> grahamtriggs: Why?
[17:20] <lcs> grahamtriggs: could it be implemented as a data type in the Describe step, though? i need to look at something similar with DOI lookups, eventually.
[17:20] <grahamtriggs> because the clocks have gone back here, and will have gone back elsewhere. Effectively, this meeting is an hour earlier for me than it was last week, and the same will be true of the Americans
[17:21] <stuartlewis> OK - I'm easy with that change - will be 10am for us rather than 9am.
[17:22] <grahamtriggs> lcs: not really. it needs to perform *before* the describe steps - or at least, it needs to be presented as a distinct page before any other metadata pages
[17:22] <grahamtriggs> and DOI is a waste of time - we have it, but the amount / quality of metadata you can retrieve is fairly pointless
[17:22] <mdiggory> grahamtriggs: We have similar needs.
[17:24] <mdiggory> I.E. form with criteria for a search... then prepopulation of item metadata afterward based on those results
[17:24] <mdiggory> whatever is in back of the search for us would vary by usecase
[17:24] <mdiggory> might even be against existing DSpace content
[17:24] <lcs> it is tempting to do that with AJAX in a Describe page too, but that would be nasty.
[17:25] <mdiggory> I want to be able to "assemble" functionality in individual units/steps so that we can repurpose.
[17:26] <kshepherd> grahamtriggs: yeah, i looked at a DOI lookup tool before i realised there was no standard way journals were presenting their metadata anyway..
[17:26] <mdiggory> I also am wary of depending on AJAX for functionality such as prepopulation of form fields
[17:26] <lcs> the crossref.org site is fairly useful in the other direction, finding DOIs for author/title, but i haven't tried mining it for metadata.
[17:27] <mdiggory> ok, grabbing a bite to eat and back to work
[17:27] <mdiggory> I
[17:27] <mdiggory> l'll be lurking
[17:29] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) Quit ("Leaving.")
[18:03] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) Quit ()
[18:12] * lcs (n=lcs@serenity.hul.harvard.edu) has left #duraspace
[20:07] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has left #duraspace
[21:43] * ksclarke (n=kevin@adsl-21-143-19.clt.bellsouth.net) has joined #duraspace
[22:06] * bradmc (n=bradmc@rrcs-208-125-23-18.nyc.biz.rr.com) has joined #duraspace
[22:38] * bradmc (n=bradmc@rrcs-208-125-23-18.nyc.biz.rr.com) Quit (Read error: 104 (Connection reset by peer))
[22:38] * bradmc_ (n=bradmc@rrcs-208-125-23-18.nyc.biz.rr.com) has joined #duraspace
[22:38] * bradmc_ is now known as bradmc
[23:09] * ksclarke (n=kevin@adsl-21-143-19.clt.bellsouth.net) Quit ("Leaving.")
[23:15] * bradmc_ (n=bradmc@rrcs-208-125-23-18.nyc.biz.rr.com) has joined #duraspace
[23:16] * bradmc (n=bradmc@rrcs-208-125-23-18.nyc.biz.rr.com) Quit (Read error: 104 (Connection reset by peer))
[23:16] * bradmc_ is now known as bradmc
[23:32] * bradmc (n=bradmc@rrcs-208-125-23-18.nyc.biz.rr.com) Quit (Read error: 104 (Connection reset by peer))
[23:41] * bradmc (n=bradmc@rrcs-208-125-23-18.nyc.biz.rr.com) has joined #duraspace
[23:47] * bradmc (n=bradmc@rrcs-208-125-23-18.nyc.biz.rr.com) Quit (Read error: 104 (Connection reset by peer))
[23:55] * bradmc (n=bradmc@208.125.23.18) has joined #duraspace
[23:59] * bradmc (n=bradmc@208.125.23.18) Quit (Read error: 131 (Connection reset by peer))
[23:59] * bradmc_ (n=bradmc@rrcs-208-125-23-18.nyc.biz.rr.com) has joined #duraspace
[23:59] * bradmc_ is now known as bradmc
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.