Timestamps are in GMT/BST.
[4:05] * ksclarke (~kevin@adsl-39-66-248.clt.bellsouth.net) Quit (Quit: Leaving.)
[6:26] * snail (~stuart@130.195.179.88) Quit (*.net *.split)
[6:26] * scottatm (~scottatm@adhcp136.evans.tamu.edu) Quit (*.net *.split)
[6:55] -card.freenode.net- *** Looking up your hostname...
[6:55] -card.freenode.net- *** Checking Ident
[6:55] -card.freenode.net- *** Found your hostname
[6:55] -card.freenode.net- *** No Ident response
[6:55] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:55] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:55] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:00] -card.freenode.net- *** Looking up your hostname...
[7:00] -card.freenode.net- *** Checking Ident
[7:00] -card.freenode.net- *** Found your hostname
[7:00] -card.freenode.net- *** No Ident response
[7:00] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[7:00] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[7:00] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:27] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[8:27] * snail (~stuart@130.195.179.88) has joined #duraspace
[8:27] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[11:32] * grahamtriggs (~grahamtri@62.189.56.2) has joined #duraspace
[12:27] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[13:01] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:08] * krnl__ (Andrius@193.219.34.106) Quit ()
[13:44] * krnl_ (Andrius@193.219.34.106) has joined #duraspace
[14:26] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:47] * scottatm (~scottatm@adhcp136.evans.tamu.edu) Quit (Ping timeout: 240 seconds)
[14:50] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:51] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[14:58] * ksclarke (~kevin@adsl-39-66-248.clt.bellsouth.net) has joined #duraspace
[17:11] * grahamtriggs (~grahamtri@62.189.56.2) has left #duraspace
[18:45] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:14] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (*.net *.split)
[19:14] * snail (~stuart@130.195.179.88) Quit (*.net *.split)
[19:14] * ksclarke (~kevin@adsl-39-66-248.clt.bellsouth.net) Quit (*.net *.split)
[19:14] * krnl_ (Andrius@193.219.34.106) Quit (*.net *.split)
[19:18] * ksclarke (~kevin@adsl-39-66-248.clt.bellsouth.net) has joined #duraspace
[19:18] * krnl_ (Andrius@193.219.34.106) has joined #duraspace
[19:18] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[19:18] * snail (~stuart@130.195.179.88) has joined #duraspace
[19:20] <snail> kshepherd: you may or may not be interested in https://secure.wikimedia.org/wikipedia/en/wiki/Wikipedia_talk:WikiProject_New_Zealand/M%C4%81ori_task_force
[19:28] <kshepherd> yep, i you passed me the link once before
[19:29] <kshepherd> happy to help where i can
[19:30] <snail> we've managed to catch the eye of the national library who're looking at updating their iwi / hapu list
[19:30] <kshepherd> very cool
[19:31] <kshepherd> i'd love an authority file i can use for iwi affiliations with performers/composers
[19:33] <kshepherd> http://iwihapu.natlib.govt.nz/iwi-hapu/index.htm isn't very API or machine-friendly (even annoying to screenscrape...)
[19:35] <snail> kshepherd: it sounds like Kim is drawing up a project plan to attract funding to update it. Sounds like they'll have to consult with a representative of every represented group though, which makes it somewhat a large project
[19:36] <kshepherd> ah
[19:36] <snail> kshepherd: the list is explicitly not avaliable for download, because they are trying to discourage use of the current version becuse it is so old and outdated
[19:36] <kshepherd> Kim.. Gutchlag?
[19:36] <snail> i have a machine readable file, but i can't really distribute it
[19:36] <snail> indeed
[19:37] <kshepherd> right
[19:37] <kshepherd> that's understandable..
[19:39] <kshepherd> google fail: browsing http://iwihapu.natlib.govt.nz/iwi-hapu/index_t.htm, Chrome tells me "This page is in Dutch, would you like to translate it?"
[19:45] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) has joined #duraspace
[19:46] * tdonohue1 (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[19:46] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Disconnected by services)
[19:46] * tdonohue1 is now known as tdonohue
[19:48] * loaner_mac_01 (~sandsfish@18.111.2.20) has joined #duraspace
[19:48] * loaner_mac_01 (~sandsfish@18.111.2.20) Quit (Client Quit)
[19:48] * sandsfish (~sandsfish@18.111.2.20) has joined #duraspace
[19:54] <tdonohue> At top of the hour, we'll be starting DSpace Developer Mtg here. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-19
[19:54] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[19:55] * cccharles (~chris@131.104.62.55) has joined #duraspace
[19:56] <grahamtriggs> kshepherd: you can't expect Google to work with made up languages...
[19:58] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) has joined #duraspace
[20:00] <tdonohue> Hi all, DSpace Developers Mtg is starting right about now. Agenda posted at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-19
[20:01] <tdonohue> We'll start off again with some JIRA reviews for the first 15-20mins. Today we'll start with DS-659. Here's a full listing of issues to review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-659+ORDER+BY+key+ASC
[20:01] <tdonohue> Collection.findAll performance issue - offset and limit improvement : https://jira.duraspace.org/browse/DS-659
[20:02] * richardrodgers (~richardro@dhcp-18-111-15-218.dyn.mit.edu) has joined #duraspace
[20:02] <mhwood> Sounds useful.
[20:02] * tdonohue hi richard, we're starting with a JIRA review. we're looking at: https://jira.duraspace.org/browse/DS-659
[20:02] <tdonohue> it does sound useful -- I wonder if it could be applied elsewhere as well
[20:03] <tdonohue> has anyone had time to take a closer look at the code / try it out?
[20:03] <tdonohue> alternatively, any volunteers to test it out further and do a small code review of sorts?
[20:03] <grahamtriggs> what happens when an item is added to / deleted from the collection whilst a client is browsing through the REST interface?
[20:04] <tdonohue> grahamtriggs -- no idea, but that's probably more of a REST issue, than directly pertaining to DS-659, isn't it?
[20:05] <mhwood> Any Oracle users here? Will there be problems with LIMIT and OFFSET?
[20:05] <grahamtriggs> tdonohue: except this issue is directly related to REST, and there isn't necessarily anywhere else where it is / would be used
[20:06] <grahamtriggs> mhwood: and yes, LIMIT / OFFSET do not work in Oracle
[20:06] <mhwood> Patch needs work then.
[20:06] <tdonohue> good point. patch definitely would need to support Oracle as well.
[20:06] <richardrodgers> Is it the patch or the API?
[20:07] <mhwood> SQL in the patch uses OFFSET and LIMIT.
[20:08] <sandsfish> So patch modifications would need to be completed by someone with an Oracle instance to test on, yes?
[20:08] <tdonohue> correct -- or anyone willing to install Oracle instance locally (you can install for free)
[20:09] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[20:09] <hpottinger> We use Oracle here, can test code
[20:09] <tdonohue> thanks hpottinger, we'd appreciate it. Feel free to add comments/results to DS-659
[20:09] <sandsfish> ( if by free you mean, $0 + the anguish of dealing with oracle ;)
[20:10] <tdonohue> Ok, in essence of time, we probably should move on to next one. If anyone else has comments, please add thoughts/comments to DS-659
[20:10] <tdonohue> Add a remote log viewer to DSpace. : https://jira.duraspace.org/browse/DS-667
[20:11] <mhwood> My first thought was: "I have SSH for that"
[20:11] <richardrodgers> Sounds like RobinT has issues
[20:11] <tdonohue> I see robin has concerns on patch itself. What do you all think about the idea? Is this something we want to support as an "idea"?
[20:12] <grahamtriggs> haven't looked at the code, but the comments aren't inspiring me with confidence that it will behave itself with very large files
[20:12] <jefftrimble> I think there are some security issues with that...I can't put my finger on it....but could it be hacked since some of our dspace installs are being served up on port 8080 instead of 8443?
[20:13] <jefftrimble> While it's only for viewing purposes, there are security issues about viewing data like that, that some institutions might officially prohibit.
[20:13] <sandsfish> I would support any DSpace administrator learning more about the workings of DSpace and troubleshooting it, but I imagine most individuals that would know what to do with the log information would have access to the log file itself. Perhaps I'm missing some use cases though...
[20:14] <tdonohue> jefftrimble: But, is it still a security issue if it's only available to DSpace Administrator? (honest question, I don't know the answer)
[20:14] <mdiggory> TBH, I'm already frustrated enough with the way dspace hardcoded logging, creating something that is dependent on it always being there raises red flags for me
[20:14] <grahamtriggs> *massive* data protection issues
[20:14] <grahamtriggs> possibly :)
[20:14] <jefftrimble> well, there are cache issues too...
[20:15] <tdonohue> ok -- sounds like there's a lot of concerns in general. Personally, I wonder if there is separate "log viewer" software that people could install specifically if they needed to view logs remotely?
[20:15] <jefftrimble> I know that at my institution, we have very stringent rules of what can and cannot be served up on port 8080 no matter who you are. That said, I'm a little leary of putting this stuff out there, but then again, we have so much admin anyways. what the heck.
[20:15] <mdiggory> chainsaw
[20:15] <jefftrimble> LOL
[20:15] <grahamtriggs> splunk
[20:15] <jefftrimble> BZZZZZZZ
[20:16] <mhwood> So you could put Global Thermonuclear War on port 9090 but not on 8080?
[20:16] <tdonohue> ok. DS-667 -- will add comment about our concerns. Suggest using either chainsaw or splunk (or similar) to view logs remotely as needed
[20:16] <mdiggory> nagios, remotely anywhere... or more simply... ssh
[20:17] <tdonohue> one more --
[20:17] <tdonohue> Pre-configure DSpace Embargo settings so that it is easier to enable. : https://jira.duraspace.org/browse/DS-668
[20:17] <jefftrimble> SSH is fine..... lazy people want http.... IMHO
[20:18] <mdiggory> just please do not create a field called dc.embargo !
[20:18] <tdonohue> DS-668 is me being frustrated with the number of questions about configuring embargo that we had on listservs immediately after it was released -- would appreciate others reactions to this...
[20:18] <richardrodgers> I'm not crazy about this - perconfiguration means we have to pick a setter, and there are already 2
[20:18] <mhwood> Yes, if we put real configuration values there, they need a namespace in which to live.
[20:19] <jefftrimble> there is no embargo element in the official DCMI terms
[20:19] <mdiggory> jefftrimble: precisely
[20:19] <tdonohue> yea, this is an area where we start to delve into whether a 'dim' schema is needed: e.g. "dim.embargo.*"
[20:19] <mdiggory> reminds me of Rob Tansleys last plea to both adding new elements to the dc namespace
[20:19] <mhwood> IIRC we need a namespace of our own anyway -- we ship with a few non-DC terms.
[20:20] <mdiggory> not dim
[20:20] <jefftrimble> Well, the whole defaul QDC in Dspace is so out of date from DCMI
[20:20] <mdiggory> http://dspace.org/system or something like that
[20:21] <tdonohue> well, yea, that could be the schema path -- but it would still need a 'short abbreviation' version. 'dim' or 'sys' or 'dsp' or whatever
[20:21] <mhwood> When I was playing with embargo, I think I made up DSpace Supplementary Metadata: dsm
[20:21] <mdiggory> dim is not a metadata namespace, is an xml format without a formal schema
[20:21] <mdiggory> ds
[20:21] <tdonohue> mdiggory -- good point. to avoid confusion we should *not* use dim
[20:21] <tdonohue> ds or 'dsm' would work
[20:21] <mdiggory> we use multiple separate namespaces for workflow and submission etc in @mire
[20:22] <tdonohue> But, getting back to the question at hand. do we like this idea? Should we create a new namespace called 'ds' or 'dsm' and preconfigure embargo fields? Or is this a bad idea?
[20:22] <grahamtriggs> ds is too close to dc - easy to get confused. What's wrong with the full 'dspace'
[20:22] <mdiggory> we limit access to these when non-admins are accessing the UI
[20:23] <mdiggory> this allows us to use them for "Item State" etc when customizing our workflows
[20:23] <tdonohue> grahamtriggs -- we could do the full 'dspace'. I have no strong feelings any which way, we'd just need to decide on something and go with it.
[20:23] <mhwood> I do like some form of the idea. This is one of those things which benefit from real examples. There is a lot left open (properly, for flexibility) and it's hard to pin it all down.
[20:24] <jefftrimble> graham's idea has lots of merit. we have too many acronyms...
[20:24] <sandsfish> +1 for dspace
[20:24] <mhwood> 'dspace' ok with me.
[20:24] <jefftrimble> +1
[20:24] <tdonohue> +1 ok with me as well
[20:24] <richardrodgers> I'm +1 for non-dc, but against re-configuraiton
[20:24] <mdiggory> supercalfragalisticexpialadocious
[20:24] <richardrodgers> pre-configuration
[20:24] <robint> From the prism schema - prism:embargoDate.
[20:25] <mdiggory> we should probibly have prism in there already... but without "qualifiers"
[20:26] <tdonohue> richardrodgers: why? also by "pre-configuration" I don't mean that it should be auto-enabled. Rather, it should be easier to enable
[20:26] <mhwood> Sounds like importing 'prism' is its own improvement request.
[20:26] <mdiggory> quite true
[20:26] <jefftrimble> if you need an embargo field, your closest standard to DCMI would but description.embargoterm and descriptoin.embargolift
[20:27] <jefftrimble> but=be something like
[20:27] <mdiggory> We've used description.embargoterm and date.embargolift
[20:27] <richardrodgers> tdonohue: you need to choose whether to have separate terms & lift fields, what the setter and lifter are, etc and all these are selectable. What are your grounds for choosing a default configuration?
[20:28] <mdiggory> because lift is a date and term is a description of the embargo period
[20:28] <jefftrimble> mdiggory: that's what I meant.
[20:28] <mdiggory> :-)
[20:28] <mhwood> I think you just stated the grounds. Everything is wide open. There are so many choices to make, it's hard to grasp how they fit together.
[20:29] <sandsfish> Is it a configuration issue or a documentation issue?
[20:29] <tdonohue> richardrodgers: I guess my grounds were more like -- it seems too complex, if people are asking a ton of questions. I'd rather they be able to "flip a switch" for an easy way to enable it. But, if they wanted they are also welcome to fully tweak all options
[20:29] <richardrodgers> gotta run, I'm sorry - but Sands will report on 1.8 etc
[20:29] * richardrodgers (~richardro@dhcp-18-111-15-218.dyn.mit.edu) Quit (Quit: richardrodgers)
[20:29] * PeterDietz (~PeterDiet@128.146.175.194) has joined #duraspace
[20:29] <tdonohue> sandsfish -- I guess it could be a docs issue as well.
[20:29] <jefftrimble> Well the dspace.cfg should have the QDC fields already filled out....
[20:30] <mdiggory> I think sane defaults are reasonable, ultimate configuration results ultimately in unpredictability
[20:30] <jefftrimble> so, if you go with mdiggory's suggestion, and add those two fields to the Schema, then its a slam dunk whether or not to comment it out or not.
[20:30] <tdonohue> +1 for sane defaults
[20:31] <robint> +1
[20:31] <snail> this seems like maybe the kind of issue that fedora might have a policy / approach on hat we can shamelessly steal?
[20:31] <snail> s/hat/that/
[20:32] <tdonohue> OK. We're at a 1/2 hour. It sounds like we still have differing viewpoints. If anyone is interesting in proposing a way to resolve this (better docs, sane defaults, both), please feel free to claim this task. We can revisit later once we have some better details in place
[20:32] <mhwood> Hmmm, maybe the concrete examples belong in the documentation. One could argue that there is *too much* in the shipping config.
[20:32] <sandsfish> +0, sane defaults sound reasonable, though I'm not familiar enough with the configuration to vote, but certainly if there are defaults, it should be off by default. a HOWTO seems like it's in order in any case.
[20:33] <tdonohue> sandsfish -- agreed, +1 to 'sane defaults', but i'm also +1 to it being "off" by default. I think there's a way to fill out the base configs with some sane defaults, while also requiring some sort of basic action (e.g. uncommenting) to actually enable embargo
[20:34] <tdonohue> Ok -- we'll stop there for now. Add more comments/suggestions to DS-668
[20:34] <jefftrimble> +1 for tdonohue's idea.
[20:35] <tdonohue> Next topic to get into: Finalizing the 1.8.0 Schedule. We've had suggestions for Sept, Oct, and "before OR12". See agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-19
[20:36] <tdonohue> It seems like (from discussion in mtgs and in dspace-commit list) most folks were in favor of Oct 2012 for 1.8. But, we had a few folks who seemed strongly against that idea. So, I thought it'd be worth some more discussion here
[20:36] <mdiggory> I actually want longer... or a beta release and a final in the early spring...
[20:36] <mhwood> OR12 is, what, 170 days away?
[20:37] <mhwood> No, 140.
[20:37] <tdonohue> mhwood -- that's OR11 :)
[20:37] <jefftrimble> If you're in academia, October seems to be a better month........the semesters start in August/September.... and you can implement upgrades during the Winter breaks.
[20:37] <tdonohue> OR12 = sometime in 2012
[20:37] <mdiggory> but I do realize my comments about syncing it to OR are difficult if OR moves around... maybe we can make a plea they stop such nonsense
[20:37] <jefftrimble> mdiggory: need a target poster for OR practicing?
[20:38] <tdonohue> mdiggory -- so, why is it that you want 'longer'? Is there a reason why you'd like to see the release period extended to something like 14-16months?
[20:38] <sandsfish> i think tying our release schedule to OR is a little to constraining, to things like release coordinator schedules, flexibility in the release process for testing, fixing bugs, etc.
[20:38] <mhwood> How resolutely do we need to chase a marketing opportunity? That's what following OR boils down to, no?
[20:38] <mdiggory> I want longer so that we can have a real meeting of the minds about architecture
[20:38] <sandsfish> i'd be more for specifying a quarter, Q1,2,3,4, and being flexible enough with the other parameters.
[20:38] <mdiggory> and develop plans for the different versions...
[20:38] <grahamtriggs> mdiggory: but practically, even if we were scheduling around an OR in June (like this year), that would mean Jan/Feb release (Mar at the absolute latest) for planning around presentations.
[20:39] <mdiggory> and I think this will not be feasable until OR
[20:39] <mhwood> So a physical meeting happens near the *start* of development, not at the *end*.
[20:39] <mdiggory> grahamtriggs: quite true
[20:39] <tdonohue> mdiggory -- so, I'm curious why you think that all those architecture changes need to be in 1.8 though. Couldn't we still have that meeting at OR10, and still do a 1.8 release in Oct (maybe with minor arch changes) followed by a future 1.9 (with larger changes)
[20:40] <mdiggory> why would you have a 1.8 release if it didn't have changes?
[20:40] <tdonohue> mdiggory: 1.8 could still have new features though -- we have lots "in the waiting" that just missed 1.7
[20:40] <mhwood> Cart before the horse -- what arch. changes need to go in?
[20:40] <mdiggory> theres no reason for a major release if there are not db changes or significant architectural changes
[20:41] <mhwood> Oops, is 1.7.1 a feature release or a bugfix release?
[20:41] <grahamtriggs> theres no reason for there NOT to be a major release if there are significant user differences
[20:41] <tdonohue> i'll point out that 1.7 didn't have significant arch changes (unless you count Mirage & such). We had no new DB fields in 1.7
[20:41] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[20:42] <mdiggory> why did we do it then and not a 1.6.3?
[20:42] <tdonohue> 1.7 was primarily a "new features & stabilization" release, which included no significant arch changes (though it added lots of new features)
[20:42] <grahamtriggs> the constraint is that we shouldn't make major architecture or db changes in a point release, not that we must have them to make it a non-point release
[20:42] <tdonohue> mdiggory -- because during the 1.6.x releases we made a joint decision that all sub-minor releases : 1.6.1, 1.6.2, had to be *bug-fix only* releases
[20:43] <mdiggory> ok ok ok
[20:43] <mdiggory> I'm on the wrong side of a loosing battle
[20:43] * mdiggory changes sides
[20:44] <tdonohue> So, if we are continuing this trend, then 1.7.1 and 1.7.2 (should we need them) should be *bug-fix only*. Then, 1.8 would be our next release with new features (and it may or may not include arch changes, depending on whether we are ready for any)
[20:44] <mhwood> I think there are some disagreements on terms. I tend to think that a "major release" is 1.x -> 2.0, a "minor release" (features added) is 1.7.x -> 1.8.0, and 1.7.1 -> 1.7.2 is bugfixes only. But there are a number of alternatives in common use.
[20:45] <robint> mhwood: that is my understanding.
[20:45] <tdonohue> mhwood: my understanding as well.
[20:45] <mhwood> (And "major" means "we broke stuff, intentionally".)
[20:46] <robint> mhwood: cant stop laughing...
[20:46] <mhwood> Anyway, whichever digit it is, do we have anything in the works which makes other code stop working?
[20:47] * mdiggory thinks we should just drop the first digit so we can be on DSpace 8
[20:47] <tdonohue> So, now that we have a more common understanding, does this change our proposed schedule for 1.8? Are we ready for a vote on this?
[20:47] <grahamtriggs> mdiggory: fair point about meeting around the architecture. The actual 2.0 work was discussed in a much smaller group than the previous architecture meeting, and whilst it was influenced by earlier meeting, it isn't necessarily the same thing. Plus we have a change in the nature of the overarching organisation to consider, which wasn't part of either meeting
[20:47] <mdiggory> cause that sounds more advanced
[20:48] <tdonohue> mdiggory has me laughing to myself...
[20:48] <mhwood> Does the Outreach Committee(?) yet have any priorities re: things users want to see?
[20:48] <robint> mdiggory: I hate to say it but it is a valid point
[20:48] <tdonohue> mhwood -- Outreach (now called "DCAT" - DSpace Community Advisory Team) has been adding their comments to various 'feature requests' already in JIRA. There have been quite a few they've reviewed and put some support behind
[20:49] <mdiggory> tdonohue: quite true, and now with service providers we have a whole new organizational dynamic at play
[20:49] <grahamtriggs> mdiggory: If I had my way, we would be planning DSpace 11.10 right now. Light years ahead :)
[20:49] <mhwood> Maybe we need to just call what we're talking about version.next until we have some idea of what it is.
[20:50] <mhwood> Aaaand, I have to go. Sorry, will catch up later.
[20:50] <tdonohue> so, I'd be open to the idea of a renumbering, if we wanted to do that -- whether it's DSpace 8 or 11.10, or 1.8, or whatever. We could call a special topic meeting to discuss, if there's enough interest here. Is there?
[20:50] <mdiggory> Anyhow, maybe we can talk a bit about features?
[20:50] <mdiggory> later mhwood
[20:51] <mdiggory> DSpace Theater 2000
[20:51] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[20:51] <tdonohue> Sure -- we can talk features. (I'll suggest a re-vote on 1.8 schedule then on dspace-commit)
[20:51] <mdiggory> We should have code namse ;-)
[20:52] <tdonohue> DSpace 8, Wildcat :)
[20:52] <tdonohue> I had put a list of potential 1.8 features I've "heard" about (and could recall) on the agenda : https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-19
[20:52] * grahamtriggs votes for the code names to be based on the works of Gerry Anderson
[20:53] <tdonohue> Essentially, if we wanted to do a "brain dump" of what we are all working on (and hope to be ready for 1.8), it might be a good place to start in terms of potential features
[20:53] <sandsfish> MIT is planning to contribute an implementation of Context-Guided Ingest, as well as additional Curation Tasks, specifically we are currently working on Format Identification, and others. That's what we've got to report so far. I hope to contribute more, but I'm not ready to commit (lower-case 'c') yet.
[20:53] * grahamtriggs and bagsies 'Captain Scarlet' as my committer identity
[20:53] * mdiggory blasts grahamtriggs with is ray gun
[20:54] * grahamtriggs is indestructible
[20:54] * tdonohue is lost on Gerry Anderson references -- I had to wikipedia him :)
[20:55] <mdiggory> Do we have a wiki page with release features thats not a meeting page
[20:55] <PeterDietz> we've been working alot on usability, in terms of making the site's content better presented for visitors, and making submissions more intuitive (with regards to where delete buttons, and next/save buttons are, etc)
[20:55] <tdonohue> We can start dumping a list of potential features on teh 1.8.0 release notes: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes
[20:55] <mdiggory> We have a few features we are planning to contribute
[20:55] <mdiggory> Context Sensitive Help for XMLUI
[20:56] <tdonohue> +1 for Context Sensitive help!
[20:56] <tdonohue> +1 for usability improvements as well
[20:56] <mdiggory> resource metadata for DSpaceObjects in general
[20:56] <PeterDietz> I also have a bunch of xmlui partial-themes that I want to share and get feedback on
[20:57] <PeterDietz> ... themes for displaying images in items, browse image gallery, simple mp3 player
[20:57] <PeterDietz> As opposed to look and feel make-over like Mirage
[20:57] <mdiggory> The whole Asyncronous release process is still in the works
[20:57] <robint> My new overlords at Edina have various things they want to contribute but I haven't picked through them yet
[20:58] <grahamtriggs> +1 metadata on all DSpaceObjects. What's the possibility of cleaning up DCValue (ie. finally removing it) at the same time? (I realise there are a lot of changes that need to be made to make that happen)
[20:58] <hpottinger> we're working on XMLUI them stuff as well, in a similar vein as PeterDietz (digital library stuff in DSpace)
[20:58] <sandsfish> Aside: I'd love to see collection homepages list browse results sorted by date by default instead of latest submissions via RSS, if anyone happens to be wandering by that code before 1.8. Don't have time to look into it yet, but that's one of our biggest UX complaints. People don't realize that they aren't being presented with the collection contents. non-intuitive.
[20:58] <mdiggory> We also are looking at further enhancements to Discovery to support ACL and Workflow state driven search which is in the Dryad version, but not in 1.7.0
[20:59] <mdiggory> grahamtriggs: we should talk because I know you have some prototyping in this area as well
[20:59] <mdiggory> DSpaceObject metadata that is
[21:00] <PeterDietz> mdiggory, would my whole understanding of asynchronous release be clearer if I thought of it as a way where upon building, maven grabs things in your module pom (such as solr / Localhostrestrcitionfilter) jar and tosses that into the whole finished product, as opposed to source that lives within the parent project?
[21:00] <tdonohue> Ok, looks like lots of new stuff in the work. Could you all take some time in the next week to add some further details (links to JIRA or Wiki pages too) here: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+1.8.0+Notes#DSpaceRelease1.8.0Notes-PotentialChangesandNewFeatures
[21:01] <grahamtriggs> mdiggory: your work is going to be more useful (mine doesn't actually function yet), but there are definitely discussions to be had around the storage requirements, and what should be possible from having these fields
[21:01] <mdiggory> PeterDietz: Async release means, dspace-api can be released under its own version identifier and depended on by external modules that are included into the final release
[21:01] <tdonohue> I've already seeded that with what I had listed on the meeting notes. I can also copy in much of what has been mentioned here. But, links to JIRA issues and other resources would be great
[21:01] <mdiggory> that modules are versioned and release independent of the formal official release
[21:02] <mdiggory> and the formal release is a configuration of exisitng individually released modules
[21:02] <mdiggory> this allow us to not have dspace-discovery and dspace-stats in the middle of trunk
[21:03] <mdiggory> and still have them released with 1.8.0
[21:03] <tdonohue> mdiggory -- in regards to async release -- we might want to talk more too. I'm in the process of making an "easy installer" -- although it's not directly related to async release, we could end up both digging in Maven poms a bit: https://jira.duraspace.org/browse/DS-802
[21:03] <mdiggory> grahamtriggs stumbled into the basic strategy in his upgrade to maven 3
[21:03] <grahamtriggs> and it also means nobody bothers to look at the source code, as it's not in their 'standard' checkout :)
[21:04] <mdiggory> no, I keep trying to get you guys to look up from the trunk and see theres a whole city of addons getting built around you
[21:05] <tdonohue> ok -- we're over time here. (1) I'll call for a final vote on 1.8 schedule on dspace-commit list, so we can formally announce. (2) everyone take some time to add details on what they are working on to the 1.8.0 release notes (and/or JIRA, as necessary)
[21:06] <mdiggory> @mire managed DSpace instances are assemblies of dspace core and addons from modules and separate @Mire managed maven repositories
[21:07] * tdonohue I'm going to go ahead and "close" the meeting. But, feel free to continue discussion. I'll hang out for a while as well.
[21:07] <mdiggory> tdonohue: yes lets talk further
[21:07] <mdiggory> about your installer
[21:08] <tdonohue> mdiggory: definitely -- I'd like your opinion on it (and anyone else's for that matter). I have an early version i'll be posting to SVN later today actually (already initiallized a branch in 'sandbox' for it)
[21:08] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) has left #duraspace
[21:08] <robint> tdonohue: You said something about it working offline ?
[21:08] <sandsfish> cheers all
[21:08] <mdiggory> Maybe we can toss around some possible requirements from the developer group
[21:09] * sandsfish (~sandsfish@18.111.2.20) Quit (Quit: sandsfish)
[21:09] <tdonohue> robint -- yes. It basically takes *all of DSpace* and packages it up into a JAR. You can install from that JAR (no need for Maven, Ant or even internet access, other than to download that JAR)
[21:10] <tdonohue> (*all of DSpace* doesn't yet include Tomcat or the DB though -- it's just all the WARs, JARs, configs, etc)
[21:10] <mdiggory> for instance, recently I've got someone experimenting with packaging tomcat into the target/dspace/... build that maven creates and trying to run the maven build directory as dspace.dir
[21:10] <mdiggory> this means that a release could be constructed that does not need to have ant run on it
[21:10] <grahamtriggs> I'm interested in the possibilities of going the other way - having a single war that can be deployed to a container, and it can create things as necessary - file system, db schema
[21:11] <mdiggory> and that dspace.dir would always be relative to the "bin" directory that the dspace script or tomcat is started from
[21:11] <tdonohue> mdiggory -- that does sound similar to my idea, though I also want to remove the need for non-programmers to have to deal with building via Maven. So, I'm going the approach of Fedora Commons, where you can install everything from a single JAR, without Maven or Ant or anything needed to build it
[21:11] <mdiggory> right, maven would be used to create the distribution, but not to install it
[21:11] <tdonohue> bingo. exactly
[21:12] <tdonohue> but, my point is that normal users do not even *create* the distribution (as they do now). I want to be able to say: (1) download this JAR, (2) run it, (3) answer the questions....and then DSpace is "installed" (guarranteed, you might need to first have a DB or Tomcat, unless we auto-install those as well)
[21:13] <mdiggory> which means that the jar has to be a container of the entire assembled distribution that was going to be installed by ant
[21:13] <tdonohue> mdiggory -- yea, it is. It has all of that within it
[21:13] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[21:13] <tdonohue> I'll post the code in a bit to SVN. I have the full install process working already (though update/upgrade is still buggy)
[21:14] <mdiggory> grahamtriggs: I'm for that too.... a war that installs itself into db and creates filesystem
[21:14] <mdiggory> the work on dspace 2 and the way the ConfigurationService loads attempted to allow for the configuration to be retrieved from relative locations.
[21:15] <mdiggory> the webapp, the servlet container working directory, user home, etc
[21:15] <mdiggory> tdonohue: I still think this would be orthogonal to async release
[21:15] <tdonohue> grahamtriggs: I'm also potentially interested in that idea. But, so far, I found this JAR installer to be easier (at least in our current install setup).
[21:16] <mdiggory> because the installer is really something that would be assembled and released
[21:16] <mdiggory> but we still need more flexibility to manage addon modules in separate source trees
[21:16] <tdonohue> mdiggory -- i agree. I think it would be. But, it only starts to "overlap" some when you ask whether someone who installs DSpace using the "installer" can then go back later on and install a new version of a module (which was just asynchronously released).
[21:17] <mdiggory> that would mean we would need an update mechanism for the installed distribution.
[21:18] <tdonohue> mdiggory -- bingo again. exactly what I've been brainstorming. still not sure the best route, but would be worth sharing our plans in more details, so that we can find something that works well
[21:18] <mdiggory> for which we currently use ant in very poor fashion
[21:19] <mdiggory> ie lib.bak and webapps.bak , etc
[21:19] <mdiggory> sorry, not poor as in bad, poor as in "poor mans"
[21:21] <tdonohue> yea. that's where I also see a need to make improvements. Currently the initial version of the installer I'm working on does that same simplistic "update" (in fact it actually uses Ant API within itself right now, to just call those same targets, unbeknownst to the actual user)
[21:21] <mdiggory> tdonohue: TBH, untill the etc and configuration directories are evaluated and work is done to bring configuration into the database, updating will always be a very very complex
[21:22] <mdiggory> Work needs to happen to bring the group to better understand "still" what we use DSpace Services and the ServiceManager for.
[21:23] <mdiggory> For instance, I have a prototype now that rewrites ScriptLauncher such that there is no longer a launcher.xml and instead the ServiceManager is used to load commands into a LauncherService
[21:24] <tdonohue> mdiggory -- interesting. is that prototype up in SVN somewhere?
[21:25] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) Quit (Quit: Page closed)
[21:28] <mdiggory> no, in my workspace, I"m trying to put together tutorial/workshop material for OR
[21:29] <mdiggory> but, once I'm ready to commit, yes
[21:30] <tdonohue> cool. sounds godo
[21:30] <tdonohue> good...not 'godo', whatever that is :)
[21:32] <mdiggory> We've actually gotten very good at using the Spring environment to assist in configuring addons being inserted into DSpace, and where before the DSpace 2.0 design was trying to make it so that you had to implement certain interfaces to use dspace.cfg style plugin definitions, we are actually favoring working directly in spring with xml and annotations over writing DSpace service manager dependent code.
[21:32] <mdiggory> sorry that was a bit of grammatical soup
[21:33] <tdonohue> i could tell it was english though :)
[21:33] <tdonohue> and I think i get the gist.
[21:34] <mdiggory> I feel that we need better "best practicies" for developing DSpace than we currently have
[21:34] <tdonohue> I wonder if there's anything in that work that @mire would be willing to put forward for 1.8.0? Or maybe you'd be willing to do a tutorial/workshop/online talk on it? It sounds like something that would be worth us all understanding a bit better..
[21:34] <mdiggory> for instance, if you start to think you need an XML file in the config directory, you should immediately sbe directed to approach the solution using spring
[21:36] <mdiggory> because if you are actually writing code to parse and map xml to java objects or configuration, then your reinventing something that is already present in the ServiceManager via Spring configuration
[21:37] <mdiggory> and likewise, you making us more and more dependent on a fixed absolute dspace.dir directory.
[21:39] <mdiggory> In the DSpace 2 work, we switched from defining where dspace.cfg was (with dspace.dir inside it) to dspace.dir being defined first and everything else always being relative to it.
[21:40] <mdiggory> the problem with having dspace.dir inside dspace.cfg is that there actually end up being two separate definitions of where dspace.dir resides.
[21:40] <mdiggory> Actually there end up being 3
[21:40] <tdonohue> as a concept, that makes sense to me...
[21:41] <mdiggory> there is the definition in the web.xml, there is the presence of the config directory relative to the bin directory on the classpath of cli applications and then there is the property in the dspace.cfg
[21:42] <tdonohue> right.
[21:43] <mdiggory> so one recommendation I am preparing is that we actually remove dspace.dir from dspace.cfg and that perhaps it should become a calculated property that is always delivered based on how dspace was started rather than a hardcoded absolute path
[21:45] <mdiggory> this would mean that rather than -Ddspace.configuration=/path/to/dspace.cfg that commandline execution would use something like -Ddspace.dir=/path/to/dir and that then the ConfigurationService would call /path/to/dir + "config/dspace.cfg" to determine if there was a configuration file present
[21:45] <mdiggory> and in web.xml
[21:46] <mdiggory> there would be the current parameter for dspace.dir used by the ConfigurationService
[21:47] <mdiggory> What this enables ultimately is that one could test dspace instances against the existing target/dspace-release-XXXX/ directories without having to run ant to install them into a more permanent location
[21:47] <mdiggory> which shortens the development cycle for testing alterations and customizations
[21:47] <tdonohue> seems like it could be a logical change. not entirely certain what all this would affect :) But, hopefully it shouldn't affect much.
[21:48] <mdiggory> it will effect folks that call the build with their own dspace.cfg
[21:49] <mdiggory> mvn package; ant fresh-install; would probibly still look the same
[21:50] <mdiggory> but if your inserting your own dspace.cfg... things change because we are actually trying to bind dspace.cfg to always be in ${dspace.dir/config/dspace.cfg
[21:51] <mdiggory> So now rather than defining in some dspace.cfg alternate locations for your dspace installation. You would need to place them ont he commandline. ant update -Ddspace.dir=/mydspacedeployment
[21:52] <mdiggory> which IMO is much more explicit than ant update -Ddspace.config=/some/dspace.cfg that possibly is no where near ${dspace.dir}
[21:53] <tdonohue> yea. again, definitely sounds logical to me. I'd just want to see the proposed patch/changes and try it out :)
[21:54] <tdonohue> FYI -- just posted a very early version of my installer to http://scm.dspace.org/svn/repo/sandbox/installer-prototype/ Very basic docs at: https://wiki.duraspace.org/display/DSPACE/InstallerPrototype
[21:54] <mdiggory> back to your installer, I think if you can design you installer.jar loosely enough, ti could also be used in the grahamtriggs war idea as well.
[21:55] <mdiggory> IE there would be an "InstallerService" or manager that has some sane defualts for where to install and creating databases etc. then a war could execute the steps of the installer as easily as the commandline
[21:55] <tdonohue> yea -- I think so, or it could morph into that later. I think the WAR idea is a good one, but IMHO I think it's a little further off, as it would likely call for an Admin UI to configs (or ideally it would). This JAR installer may be a step towards that
[21:56] <mdiggory> Yes, the war approach requires creating a webapp interface for mediating the install rather than a commandline one.
[21:58] <tdonohue> currently, the JAR installer is *extremely* simplistic. Just one Java class, which actually just makes Ant API calls to call a build.xml in a more automated way. User just sees it as a basic Q&A though, they wouldn't necessarily realize it's actually running the same (or similar) Ant install scripts they currently exist.
[21:58] <mdiggory> Another project that should be added to possible suggestions for 1.8.0 would be to pull the database configuration out of dspace.cfg and store it elsewhere preferably in a 'manner that it can be defined or over=riden by Spring and the servlet engine
[21:59] <mdiggory> yes, you can run ant programatically htat way... I beleive we are already relying on ant as a dependency now, so if written properly, it would already be present in dspace.
[22:01] <mdiggory> Another idea for your installer, in the absence of a proper database, fire up the in-memory db used in the junit testing.
[22:01] <mdiggory> Are you considering providing a servlet container in the installer?
[22:01] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[22:04] <mdiggory> tdonohue: for instance being able to start a jetty instance or the like so that the installer could actually be used to demo dspace or for testing
[22:04] <tdonohue> mdiggory -- right now, I was just trying to build something simple that *works*. So, there's a lot of various ways this could go. But, I started with making Ant API calls to make it as similar to how it currently works
[22:05] <tdonohue> mdiggory -- oh, yea.. along that route, was thinking about potentially embedding tomcat/jetty (like Fedora Commons does -- it offers option to auto-install Fedora into pre-configured Tomcat)
[22:05] <tdonohue> so, this installer could potentially ask if you want it to autoinstall Tomcat and even a basic in-memory DB for a "quick install" option
[22:06] <tdonohue> but, right now -- it's just a simple wrapper of Ant :)
[22:49] * ksclarke1 (~kevin@adsl-39-65-246.clt.bellsouth.net) has joined #duraspace
[22:51] * ksclarke (~kevin@adsl-39-66-248.clt.bellsouth.net) Quit (Ping timeout: 276 seconds)
[23:08] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[23:12] * ksclarke1 is now known as ksclarke
[23:32] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[23:57] <snail> http://oldwiki.dspace.org/ is dead
[23:59] <stuartlewis> http://oldwiki.dspace.org/ is dead. Long live http://oldwiki.dspace.org/.
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.