#duraspace IRC Log

IRC Log for 2011-06-29

Timestamps are in GMT/BST.

Conversation with #duraspace at 6/29/2011 8:41:22 AM on irc.freenode.net (irc)

NOTE: All Times below are CDT. DuraLogBot had issues logging today, and these logs were captured instead by tdonohue's IRC client

(11:31:20 AM) grahamtriggs left the room.
(11:56:26 AM) marcmcd [~marcmcd@bas16-ottawa23-1176333776.dsl.bell.ca] entered the room.
(12:00:14 PM) marcmcd left the room.
(2:32:40 PM) grahamtriggs [~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com] entered the room.
(2:48:28 PM) KevinVdV [~KevinVdV@d54C14B16.access.telenet.be] entered the room.
(2:52:27 PM) tdonohue: Hi all - Reminder we have our weekly DSpace Devel Mtg here at top of the hour: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-29
(2:52:28 PM) kompewter: [ DevMtg 2011-06-29 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-29
(2:58:25 PM) hpottinger [80cea2c6@gateway/web/freenode/ip.128.206.162.198] entered the room.
(2:58:48 PM) aschweer [~schweer@schweer.its.waikato.ac.nz] entered the room.
(2:59:26 PM) richardrodgers [~richardro@pool-96-237-109-89.bstnma.fios.verizon.net] entered the room.
(3:00:48 PM) mdiggory [~mdiggory@rrcs-74-87-47-114.west.biz.rr.com] entered the room.
(3:00:58 PM) tdonohue: Hi all, looks like it's that time again. Here's our DSpace Devel Mtg agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-29
(3:00:59 PM) kompewter: [ DevMtg 2011-06-29 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-29
(3:01:30 PM) tdonohue: We'll start things off with a Quick JIRA review for the first 15-20 minutes or so. Here's the list of JIRA issues we're working from: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-820+ORDER+BY+key+ASC
(3:01:31 PM) kompewter: [ https://jira.duraspace.org/browse/DS-820 ] - [#DS-820] SFX button + SFX in Mirage - DuraSpace JIRA
(3:01:34 PM) kompewter: [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-820+ORDER+BY+key+ASC
(3:01:38 PM) tdonohue: We'll start with DS-820
(3:01:39 PM) kompewter: [ https://jira.duraspace.org/browse/DS-820 ] - [#DS-820] SFX button + SFX in Mirage - DuraSpace JIRA
(3:01:59 PM) mhwood: Assigned
(3:02:28 PM) tdonohue: yep, looks like this one is assigned. I doubt kshepherd is here yet (early for him), so we'll just assume he's still taking care of this on.
(3:02:42 PM) tdonohue: Next up, DS-824
(3:02:42 PM) kompewter: [ https://jira.duraspace.org/browse/DS-824 ] - [#DS-824] Request Copy function for XMLUI; would allow author of item to give viewing privs to restricted item - DuraSpace JIRA
(3:02:49 PM) robint [522921b0@gateway/web/freenode/ip.82.41.33.176] entered the room.
(3:02:51 PM) tdonohue: ack. Wait..next is DS-822
(3:02:52 PM) kompewter: [ https://jira.duraspace.org/browse/DS-822 ] - [#DS-822] Default dc metadata schema not used when selecting fields from DIM for default item display - DuraSpace JIRA
(3:03:18 PM) ***tdonohue notes we'll do ds-824 after ds-822
(3:03:19 PM) kompewter: [ https://jira.duraspace.org/browse/ds-824 ] - [#DS-824] Request Copy function for XMLUI; would allow author of item to give viewing privs to restricted item - DuraSpace JIRA
(3:03:21 PM) kompewter: [ https://jira.duraspace.org/browse/ds-822 ] - [#DS-822] Default dc metadata schema not used when selecting fields from DIM for default item display - DuraSpace JIRA
(3:04:37 PM) richardrodgers: looks like a little further work needed (ds-822)?
(3:04:38 PM) kompewter: [ https://jira.duraspace.org/browse/ds-822 ] - [#DS-822] Default dc metadata schema not used when selecting fields from DIM for default item display - DuraSpace JIRA
(3:04:49 PM) scottatm: yes it does.
(3:05:17 PM) tdonohue: yes. looks like that's the case. Any volunteers to update Claudia's patch for Ds-822, based on kshepherd's notes?
(3:05:44 PM) tdonohue: (i.e. this seems like a rather easy fix, if someone wants to tackle it quickly)
(3:07:12 PM) tdonohue: No one? ok. We'll just schedule Ds-822 for 1.8 and leave it unassigned for now. Hopefully Claudia or kshepherd can finish this up..
(3:07:22 PM) tdonohue: Next up, DS-824
(3:07:23 PM) kompewter: [ https://jira.duraspace.org/browse/DS-824 ] - [#DS-824] Request Copy function for XMLUI; would allow author of item to give viewing privs to restricted item - DuraSpace JIRA
(3:07:49 PM) richardrodgers: scottatm: you folks still interested in this (working on it)?
(3:07:53 PM) tdonohue: this is assigned to scottatm. need any help or feedback scott?
(3:08:04 PM) scottatm: A&M is working on this.... We have it implemented for XMLUI, we plan to implement it also in JSPUI.
(3:08:20 PM) tdonohue: Ok, sounds good. we'll move on then. Thanks, scottatm!
(3:08:31 PM) tdonohue: Next up, DS-826
(3:08:32 PM) kompewter: [ https://jira.duraspace.org/browse/DS-826 ] - [#DS-826] LDAPServlet.java incorrectly redirects to incorrect.jsp rather than ldap-incorrect.jsp - DuraSpace JIRA
(3:09:02 PM) richardrodgers: just need an LDAPper to verify?
(3:09:52 PM) bradmc [~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com] entered the room.
(3:09:56 PM) tdonohue: anyone want to verify this? Someone have an LDAP handy?
(3:11:34 PM) tdonohue: wow, simply no volunteers today :) and these seem like easy ones!
(3:12:39 PM) tdonohue: Summary for Ds-826: Schedule for 1.8.0 as it seems to be a minor fix. Needs a volunteer to test with LDAP.
(3:12:43 PM) robint: No ldap (handy excuse!)
(3:12:54 PM) mdiggory: Sorry, I"m afraid I'm lurking...
(3:13:06 PM) scottatm: A&M is all shibboleth....
(3:13:12 PM) richardrodgers: same here...
(3:13:34 PM) aschweer: doesn't stuartlewis have a test ldap somewhere? if he does then I can give this a quick test
(3:14:12 PM) tdonohue: he might. I'm not sure, aschweer, but that sounds like something stuartlewis would have :)
(3:14:15 PM) ablemann: hm
(3:14:17 PM) ablemann: I can confirm it.
(3:14:47 PM) tdonohue: ablemann : you already tested this? Or you are volunteering to test it? (just want to clarify)
(3:15:11 PM) ablemann: I just tested it and it seems to be correct. I can post that in the ticket.
(3:15:20 PM) ablemann: correct as in the bug report is correct
(3:15:51 PM) tdonohue: thanks, ablemann. If you want to claim that in the ticket, we can go ahead and get it committed. It looks like an obvious bug to me, but we just need someone to vouch for the fix :)
(3:16:24 PM) tdonohue: moving on to our next ticket... DS-827
(3:16:25 PM) bradmc left the room (quit: Read error: Connection reset by peer).
(3:16:25 PM) kompewter: [ https://jira.duraspace.org/browse/DS-827 ] - [#DS-827] Autoregister in LDAPHierarchicalAuthentication is incompatible with ldap.netid_email_domain option - DuraSpace JIRA
(3:16:50 PM) tdonohue: another LDAP one, looks like
(3:17:52 PM) bradmc [~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com] entered the room.
(3:17:52 PM) ***tdonohue notes we need to find someone who is running LDAP to help verify these fixes
(3:18:16 PM) aschweer: http://blog.stuartlewis.com/2008/07/07/test-ldap-service/ but I don't know if the test ldap server is still up
(3:18:18 PM) kompewter: [ Stuart Lewis' Blog » Test LDAP service ] - http://blog.stuartlewis.com/2008/07/07/test-ldap-service/
(3:19:38 PM) tdonohue: well, maybe we can ask stuartlewis about these if he comes online later
(3:20:33 PM) tdonohue: ok. Summary for Ds-827: Again, needs a volunteer with LDAP to verify solution. Ask stuartlewis if he's still got a test LDAP available.
(3:21:16 PM) tdonohue: ok. we're at 20 minutes, so we'll stop there for today.
(3:21:40 PM) tdonohue: General Announcements now...
(3:22:01 PM) tdonohue: since she's here in attendance, another congrats/welcome to aschweer, our newest Committer!
(3:22:11 PM) aschweer: thanks :)
(3:22:19 PM) mdiggory: Welcome
(3:22:20 PM) mhwood: Welcome!
(3:22:32 PM) richardrodgers: welcome and thanks aschweer !
(3:22:52 PM) ***grahamtriggs would stand and applaud, but that would mean putting the laptop down
(3:23:11 PM) aschweer: thanks everyone :) Stuart is working on getting me sorted with permissions etc
(3:23:29 PM) tdonohue: Also, as I've sent out to -devel, we have a new "Unreleased Documentation" wiki area, where everyone can start to add in their 1.8.0 documentation updates immediately: https://wiki.duraspace.org/display/DSDOCDEV
(3:23:30 PM) kompewter: [ DSpace Documentation - DSpace Unreleased Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOCDEV
(3:24:34 PM) tdonohue: this means that I fully expect to see mdiggory creating amazing documentation there in the coming weeks/days (I'm teasing mdiggory, cause he hates writing docs)
(3:24:51 PM) mdiggory: hey... thats not true ;-)
(3:24:56 PM) tdonohue: haha ;)
(3:25:00 PM) mdiggory: I love writing docs ;-)
(3:25:04 PM) tdonohue: (just seeing if you were paying attention there)
(3:25:07 PM) mhwood: So now DSDOC is just a place that DSDOCDEV gets copied to on release?
(3:25:34 PM) tdonohue: correct, mhwood. DSDOC is now the "officially released docs". It's the place that DSDOCDEV will be copied to on release
(3:25:52 PM) aschweer: and if we find a bug in DSDOC, do we fix it in both places?
(3:26:45 PM) tdonohue: unfortunately, yes. DSDOC will essentially get "overwritten" by what is in DSDOCDEV during the release process. There's no easy way to "merge" things. So, if the bug needs immediate fixing (before 1.8) then it needs to be fixed in two places
(3:27:02 PM) aschweer: thanks tdonohue, good to know
(3:28:02 PM) tdonohue: I'll admit, I'm still working on the DSDOCDEV -> DSDOC release process. I'm leaning heavily on Fedora & DuraCloud folks, and we are all trying to figure out the easiest way to manage docs in Confluence.
(3:28:19 PM) hpottinger: tdonohue: do tools exist to help finding conflicts between versions?
(3:28:22 PM) richardrodgers: Have they had that process in place for a while?
(3:28:48 PM) tdonohue: hpottinger: no, Confluence is limited in tools to find "conflicts" across two different wiki spaces
(3:29:26 PM) tdonohue: richardrodgers: currently, DuraCloud has a docs process they've had in place for a while. Fedora is trying to simplify their processes (based on limitations of Confluence).
(3:30:34 PM) hpottinger: if it's mostly an eblow-grease-powered process, these elbows volunteer
(3:30:41 PM) tdonohue: essentially the biggest issue here is that Confluence doesn't let you "merge" differences between spaces easily. You can only copy/move contents. Which means right now, during a release, the contents of DSDOC would be "replaced" by DSDOCDEV
(3:31:01 PM) richardrodgers: so regression is an issue
(3:31:22 PM) mhwood: More docs to read: what's a "space"?
(3:31:49 PM) tdonohue: "space" = An "area" of the Confluence Wiki. DSDOC is a "space", so is DSDOCDEV
(3:32:54 PM) tdonohue: So -- in the end, still working on ways to improve this Documentation process. But, I think we already identified that DSDOCDEV is of benefit -- it lets us write 1.8 docs right away (while people are still referring to 1.7.2 docs in DSDOC)
(3:33:08 PM) grahamtriggs: Why don't we do what Atlassian does, and maintain an archive of the different versions of the documentation?
(3:33:31 PM) tdonohue: grahamtriggs: we can do that. That's what DuraCloud actually does (and Fedora may move that way too).
(3:33:48 PM) tdonohue: using that process we'd do something like this during a release:
(3:34:06 PM) tdonohue: (1) Move DSDOC to "DSDOC17" (1.7.x Docs) as an "archive"
(3:34:19 PM) tdonohue: (2) Move DSDOCDEV to DSDOC (to release 1.8 docs)
(3:34:44 PM) tdonohue: that's what DuraCloud does
(3:35:28 PM) richardrodgers: we surely need x-n docsets, where x = current
(3:36:18 PM) tdonohue: not sure I understand that statement, richardrodgers?
(3:36:38 PM) richardrodgers: I mean, we can't lose 1.7 when 1.8 appears
(3:37:11 PM) tdonohue: right. Currently, our process is that we create a PDF & HTML copy as "archived" copies of the past docs (just like for 1.6 and previous)
(3:37:12 PM) richardrodgers: And I mean 1.7 as a living doc, since there may be corrections
(3:37:32 PM) aschweer: I have to leave, bye everyone
(3:37:36 PM) aschweer left the room (quit: Quit: leaving).
(3:38:11 PM) tdonohue: yea, I can see that as a point. That's why DuraCloud & Fedora chose that route as well. So, I'd be fine with going that way and creating a DSDOC17 space to "archive" the 1.7.x docs when we release 1.8
(3:38:27 PM) ***hpottinger has to leave, too, but is thinking about the potential of the Confluence to XML export for comparing versions
(3:39:01 PM) tdonohue: hpottinger -- I'd welcome you to play around with it :) We are looking for other ideas
(3:39:28 PM) mdiggory: I think resources are too thin to support separate branches of documentation... retire old versions of the docs to PDF/HTML and abandon supporting changes to them...
(3:39:45 PM) mdiggory: Focus all resources on providing the best current documentation possible
(3:40:00 PM) mdiggory: eventually, that will filter into previous versions over the comming years
(3:40:13 PM) hpottinger left the room (quit: Quit: Page closed).
(3:40:17 PM) mhwood: Current documentation describes current code. Not every site runs current code all the time.
(3:40:27 PM) richardrodgers: we may indeed be resource-constrained, but it seems to me to be the big win of using wikis....
(3:40:40 PM) mdiggory: thats why you have a pdf/html for your version
(3:40:54 PM) tdonohue: mdiggory: just cause we "archive" things off on the Wiki (to DSDOC17 or similar) doesn't mean we need to actually continue to modify them. DuraCloud actually makes "archived" spaces read-only, and only modifies them if something is blatantly wrong
(3:41:01 PM) mdiggory: and dsdocdev / dsdoc for the current
(3:41:45 PM) mdiggory: tdonohue: why not save the space and just push them to "non-editable" format
(3:41:52 PM) richardrodgers: yes tdonohue, that's the sort of scenario I mean
(3:42:28 PM) mhwood: DSDOC17-ERRATA....
(3:42:39 PM) tdonohue: So, we could basically do something like: DSDOC -> current released version of docs, DSDOCDEV -> in process docs for next major release , DSDOCXX -> "archive" of docs (read-only unless we really need to change something)
(3:43:31 PM) mdiggory: I'm sure at some point the Duraspace community is going to experience "Confluence Space Bloat" and start restricting space creation...
(3:44:22 PM) mdiggory: I consider Confluence to be a publishing workflow, not the final form.
(3:44:27 PM) tdonohue: mdiggory -- currently creating new spaces costs next-to-nothing. But, if we did achieve "space bloat", all we'd need to do is export PDF/HTML from old spaces and delete them at that point
(3:44:50 PM) mdiggory: I'm sure, quite true
(3:45:11 PM) tdonohue: mdiggory -- another issue is that Confluence "publishes" extremely ugly HTML (have you seen it) :)
(3:45:32 PM) mdiggory: Just trying not to open a pandoras box of "create this line of text in N different versions of docs"
(3:45:45 PM) mdiggory: gzip
(3:45:59 PM) mdiggory: oh, I thought you said "huge"
(3:46:01 PM) tdonohue: mdiggory -- but it's no "pandora's" box if you make the old docs *read-only*
(3:46:35 PM) mdiggory: \me how did I get into this discussion. should've kept my mouth shut
(3:47:16 PM) ***mdiggory puts down shovel, stops digging hole
(3:47:23 PM) tdonohue: yea, I think we need to "table this" for now. Obviously more discussion is needed. But, I'd like to continue to discuss options with DuraCLoud & Fedora folks -- hopefully we can all find something that will work for all of us
(3:48:06 PM) grahamtriggs: Unless there is a *serious* documentation flaw, we shouldn't edit the docs of 'published' releases, unless we're gearing up for a .1, .2, etc. release
(3:48:49 PM) tdonohue: right, grahamtriggs. that's what I meant by "read-only". We don't modify those old published docs unless something is so blatantly wrong it is embarrassing :)
(3:48:57 PM) ***mdiggory glares at grahamtriggs
(3:49:02 PM) tdonohue: ok. Going to move on now, in the essence of time
(3:49:23 PM) tdonohue: robint asked that we all take a moment to discuss DS-935
(3:49:24 PM) kompewter: [ https://jira.duraspace.org/browse/DS-935 ] - [#DS-935] REST-API Has a dependency on the dspace-jspui-api, it would be nice if this could be removed. - DuraSpace JIRA
(3:49:51 PM) mdiggory: yes, please delete dspace-jspui from the codebase
(3:50:03 PM) scottatm: lol
(3:50:27 PM) robint: The nub of the question is whether to go for the quick fix of moving a few classes out of jspui into dspace-api
(3:50:32 PM) tdonohue: Specifically, the REST API has a dependency on JSPUI-API (ugly, yea). We want to move this code out of the JSPUI-API as it doesn't belong there. The question is whether we move this code to 'dspace-api', or whether we create a "Business Logic Layer API" immediately
(3:50:52 PM) robint: Well put tdonohue
(3:51:22 PM) mdiggory: I think you copy the code for now... seems the same approach that grahamtriggs et al. have taken with webmvc
(3:51:22 PM) grahamtriggs: dspace-api *is* a / the business logic layer
(3:51:59 PM) richardrodgers: I just think, if there is eventually going to be a dependency that *is not* dspace-api, why move twice?
(3:53:09 PM) tdonohue: grahamtriggs: yes, it is right now. But, recall all those discussions about a "Business Logic Tier", shared across the various UIs. The question is do we start to do that right now (i.e. for 1.8). Or do we just keep dspace-api as that "business logic" until we get around to larger refactoring
(3:53:11 PM) richardrodgers: hold your nose for now, and suffer the jsp-api stupidity, and don't get trapped....
(3:53:14 PM) robint: I am sympathetic to the idea of splitting up dspace-api, but I have no clear view of what is required at this moment in time
(3:54:01 PM) mdiggory: Why do we have a "reacentSubmissionsmanager"?
(3:54:33 PM) tdonohue: mdiggory: is that a philosophical question :)
(3:54:39 PM) grahamtriggs: keep dspace-api until we have a clearer idea of what we are refactoring, and to where. More importantly, we need to actually refactor the *code* to do any artifact splitting properly - so it might as well all be in dspace-api, for now
(3:54:43 PM) mdiggory: or an exception?
(3:55:11 PM) robint: grahamtriggs:+1, although I am willing to be convinced otherwise
(3:55:16 PM) mdiggory: XMLUI doesn't need this code for sure...
(3:55:59 PM) bradmc left the room (quit: Ping timeout: 240 seconds).
(3:56:04 PM) robint: mdiggory: I had a bried look at the xmlui and I think it duplicates some of the code in RecentSubmissionsManager
(3:56:16 PM) robint: bried/brief
(3:56:18 PM) mdiggory: Discovery is a search query
(3:56:56 PM) robertqin [~robertqin@bb116-14-148-121.singnet.com.sg] entered the room.
(3:57:06 PM) tdonohue: mdiggory, but what if you aren't using Discovery with XMLUI. I thought there still is an equivalent to the "Recent Submissions"
(3:57:10 PM) mdiggory: recent submissions is Application logic.... a search sorted by date
(3:57:41 PM) mdiggory: in xmlui its a browse by date
(3:57:54 PM) mdiggory: in jspui is a browse sorted by date
(3:58:02 PM) grahamtriggs: RecentSubmissions has nothing (or very little) to do with HttpServlets - they don't import any of the servlet classes / interfaces. So they should also be moved to a different package, not 'org.dspace.app.webui.components'
(3:58:08 PM) mdiggory: its presentational
(3:58:55 PM) tdonohue: so, mdiggory, what are you arguing for? You want this RecentSubmissionsManager logic copied into the REST API itself, rather than moved to dspace-api?
(3:58:58 PM) mdiggory: I'm not feeling it... My vote is to copy it, the code is minimal and focused on presentation
(3:59:11 PM) mdiggory: its application code, not buisness logic
(3:59:12 PM) robint: mdiggory: there are 3 classes that retrieve the data and 2 that present it (in the jspui)
(3:59:28 PM) robint: I want to move the 3 that retrivev the data
(3:59:49 PM) robint: so that the REST api can use them without being dependent on the jspui
(4:00:04 PM) robint: the 2 classes that are presentational will stay in the jspui
(4:00:07 PM) gaurav_kl [75c62166@gateway/web/freenode/ip.117.198.33.102] entered the room.
(4:00:15 PM) mdiggory: thats what I'm saying, copy them to the REST library if thats were your using them.
(4:00:27 PM) tdonohue: robint: so, it sounds like mdiggory is just recommending rather than *move* those 3, you just copy them to the REST API (thus, you can still remove that dependency, as the REST API will no longer need to reference the JSPUI version)
(4:00:56 PM) grahamtriggs: You can't just classify it as application code when you have to deal with a large dataset - this cuts back into asking the underlying storage to return data in the correct order to be efficient.
(4:01:01 PM) robint: Ok. But that seems odd to have identical classes in 2 places
(4:01:04 PM) mdiggory: right, we are talking about < 200 lines of code
(4:01:10 PM) tdonohue: is that another plausible solution, robint? Or is there an issue here we aren't seeing?
(4:01:46 PM) tdonohue: robint : yea, I can understand that concern. It's not DRY (don't repeat yourself)
(4:02:14 PM) mdiggory: DRY is overrated
(4:02:26 PM) robint: tdonohue: its fine for me
(4:03:22 PM) mdiggory: the problem with acronyms arises when people use them
(4:03:26 PM) robint: Although I confess I don't understand the logic
(4:03:49 PM) scottatm: The logic is if you find a bug in that code, then you'll have to fix it twice.
(4:03:50 PM) mdiggory: my logic?
(4:04:14 PM) robint: mdiggory: yes
(4:06:09 PM) mdiggory: The logic is that abuse of DRY in multi-tier applications results in creating "super node" centralized dependencies on the similar code that make modularization difficult
(4:06:44 PM) mhwood: How does using libraries make modularization difficult?
(4:06:47 PM) mdiggory: everything has to dependend on dspace-api because we keep cramming code in there when we think its needing to be "shared"
(4:07:23 PM) mdiggory: mhwood: not just any libraries...
(4:08:10 PM) mhwood: Why is it so wrong to depend on dspace-api?
(4:09:12 PM) mdiggory: its not wrong to depend on dspace-api... but be aware it is...
(4:09:15 PM) mdiggory: 1.) misnamed
(4:09:26 PM) mdiggory: 2.) is not properly modularized yet itself
(4:09:46 PM) tdonohue: I think mdiggory's bigger point here is that we are cramming a lot into dspace-api -- which I can agree with. Hence, the desire to refactor. But, since we don't want to hold this up to wait for larger refactoring, we need to do something.
(4:09:46 PM) mdiggory: 3.) spans both the business and persistence tiers
(4:10:07 PM) stuartlewis [~stuartlew@s-lewis.itss.auckland.ac.nz] entered the room.
(4:10:21 PM) mhwood: So there are things we should move into dspace-api and things we should move out of it.
(4:10:32 PM) mdiggory: The big question is: Is there really anything of benefit int he RescentSubmissions code that warrants centralizing it other than DRY
(4:10:39 PM) robint: tdonohue: So the answer is to cram it into the REST api instead ? :)
(4:11:11 PM) mdiggory: and IMO, < 200 lines of code that organize a Browse Query for presentation in the JSPUI do not warrant being called Buisness Logic
(4:11:40 PM) mdiggory: robint: yes, because then the code is where its used
(4:11:42 PM) grahamtriggs: tdonohue: I honestly think it's the other way round - if we go out of our way to not put things [that need re-organizing in themselves] into dspace-api, then we are holding up the larger refactoring even more
(4:12:54 PM) mdiggory: robint: In the REST case, the output is "presentation" if you were writing this using Spring REST, this logic would be a Controller
(4:13:20 PM) tdonohue: ok. we're going quite over time here. Should we just vote on this?
(4:13:49 PM) bojans [~Bojmen@62.68.118.148] entered the room.
(4:13:58 PM) mdiggory: the Controller would organize the model for Presentation and pass it to the View for rendering... the recentSubmissions code is not business logic, the Browse system its calling is
(4:13:58 PM) richardrodgers: I don't think it is a big deal either way in the near term, but it strikes me as ironic that we all appear to want a rational refactor of dspace-api, and we start out by throwing more stuff in it..
(4:14:17 PM) mhwood: lacking somewhere else to throw it....
(4:15:00 PM) mhwood: ...and a model to guide us as to what gets thrown where....
(4:16:26 PM) robint: I'm more confused than when I started, happy to go with the majority
(4:16:47 PM) tdonohue: I've heard three options: Option #1 - Move the offending code to dspace-api , Option #2 -- Duplicate the code entirely in REST API, Option #3 - Create a new Business layer api immediately (dspace-ui-api or dspace-logic-api or similar) and move the code there. Consider this the first code to get "refactored" to that area.
(4:17:14 PM) tdonohue: shall we vote?
(4:17:18 PM) mdiggory: we just got done ridding ourselves of dspace-ui-shared.
(4:17:38 PM) scottatm: I vote #2, untill someone has a solid plan for #3
(4:17:41 PM) mdiggory: because of one very important reason... the work going on in xmlui was divergent from jspui
(4:18:18 PM) KevinVdV: Take into account please that discovery has its own way of dealing with determining which items where submitted last
(4:18:20 PM) mdiggory: and we don't want the shared dependency to pigeon hole xmlui development
(4:18:28 PM) tdonohue: ok, Option#2 has +1
(4:18:55 PM) mdiggory: Option 2 +1
(4:19:03 PM) mhwood: Bingo, we have two different ways of determining recently-submitted and we're talking about creating a third.
(4:19:12 PM) mhwood: So what does "recently-submitted" mean?
(4:19:21 PM) richardrodgers: +1 Option #2, but don't give up on shared logic jars...
(4:19:41 PM) tdonohue: Option #2 has +3 votes...anyone else voting?
(4:19:43 PM) mdiggory: They are on two completely different implementations, of course they are different
(4:19:53 PM) mhwood: Option 1 +1
(4:20:04 PM) grahamtriggs: opt 1 + 1
(4:20:30 PM) bojans: #2 +1
(4:20:45 PM) mhwood: So does "recently-submitted" mean what Discovery thinks it means, what JSPUI thinks it means, or what XMLUI thinks it means?
(4:21:01 PM) KevinVdV: Well for discovery it is configurable
(4:21:16 PM) mdiggory: mhwood: Recent Submissions is a presentation concept, its upto the application to define it.
(4:21:28 PM) tdonohue: Ok. Looks like we still have some minor disagreements here, but Option #2 looks to be the winner. (I'll admit I'm torn between #1 and #2, so I'm abstaining)
(4:21:51 PM) robint: Democracy in action :)
(4:22:00 PM) mhwood: I would have voted for #3 if it was well-defined and the remains of dspace-api were well-defined.
(4:22:14 PM) scottatm: mhwood, I agree.
(4:22:53 PM) tdonohue: mhwood, I'd agree with you too. That's a discussion that will have to wait for another time (but, we should schedule a Special Topics Meeting on that one)
(4:22:57 PM) mdiggory: TBH, if you've looked at the code, you will understand we are arguing over about 40 lines of "making a Browse query"
(4:23:28 PM) mdiggory: other parts of the UI's make this call themselves
(4:24:05 PM) richardrodgers: gotta run, thanks all
(4:24:12 PM) tdonohue: Ok. That's it for today's Devel meeting. We've already "eaten" into nearly 25 minutes of the GSoC Update Meeting time.
(4:24:12 PM) richardrodgers left the room (quit: Quit: richardrodgers).
(4:24:29 PM) robint: Ok, got to go. Thanks for making time for that discussion. Cheers.
(4:24:34 PM) mhwood: Yes, I must go too. Thanks!
(4:24:39 PM) tdonohue: So, everyone is welcome to stick around. I'd suggest we switch over to GSoC topics
(4:24:43 PM) robint left the room.
(4:24:44 PM) mhwood left the room.
(4:25:46 PM) tdonohue: bojans requested that as part of the GSoC meeting we talk about "infrastructure". I know that at least one project would like a "virtual server" for demos, etc
(4:26:03 PM) mdiggory: yes, that is truew
(4:26:24 PM) mdiggory: liked the free AWS tier idea
(4:26:27 PM) bojans: yes, i supposed it would probably better to discuss that in this live session
(4:26:47 PM) bojans: in order to try not to lose time for GSoC
(4:26:52 PM) KevinVdV left the room (quit: Quit: KevinVdV).
(4:27:34 PM) tdonohue: So, I talked to others at DuraSpace about this idea. As mdiggory mentioned, we were wondering if the Free AWS Tier would work for this: http://aws.amazon.com/free/
(4:27:35 PM) kompewter: [ AWS Free Usage Tier ] - http://aws.amazon.com/free/
(4:27:57 PM) bojans: ok seems that aws could offer enough resources for that purpose
(4:28:14 PM) bojans: 613mb of memory
(4:28:28 PM) bojans: and storage offered is pretty enough
(4:28:52 PM) tdonohue: Essentially, anyone can get a Free AWS server set up. However, you do need to enter in a credit card. But, as I mentioned, if somehow Amazon started charging you (e.g. you used more than the Free Tier allows) then DuraSpace could reimburse your costs (up to a limit)
(4:29:39 PM) bojans: also I think all GSoC students already have credit card available for setup, those from Google at least
(4:29:45 PM) scottatm: wow, I didn't know they had a free teir!
(4:29:50 PM) bojans: me too :)
(4:29:53 PM) scottatm: (even if it is for a year)
(4:30:23 PM) tdonohue: So, also the "Free Tier" only lasts 12 months. So, you would need to make sure to shutdown your AWS server before one year is up (otherwise you would get charges). Also, DuraSpace could *ONLY* reimburse you during GSoC (and not afterwards)
(4:30:33 PM) mdiggory: makes sense... better make sure students don't get into a bad spot with AWS if the instance costs suddenly change...
(4:30:59 PM) mdiggory: anything we can do to buffer/protect them and us?
(4:31:44 PM) tdonohue: we're open to ideas, to be honest. Again, this is just the first ideas from DuraSpace. So, if anyone else has ideas, we'd love to hear them.
(4:32:55 PM) bojans: for AWS, for me looking at the documentation, it seems we should digg more to get info about overusage of resources
(4:33:06 PM) mdiggory: tdonohue: any way with the free tier to stop the instance if it starts "charging" for use
(4:33:10 PM) bojans: standard info page says it will automaticaly bill overusage
(4:34:05 PM) tdonohue: mdiggory: DuraSpace would not have a way to stop the instance, as it would not be tied to our AWS account. However, the student or mentor (or whoever created the AWS account) would be able to start/stop instances as much as they wanted to
(4:34:08 PM) mdiggory: how good for them
(4:34:16 PM) bojans: http://aws.amazon.com/cloudwatch/
(4:34:17 PM) kompewter: [ Amazon CloudWatch ] - http://aws.amazon.com/cloudwatch/
(4:34:19 PM) mdiggory: AWS, not Duraspace
(4:34:28 PM) bojans: it is possible to setup alarms to get notifications
(4:34:44 PM) bojans: also it seems there is API available
(4:35:10 PM) mdiggory: cloudwatch sounds acceptable
(4:35:44 PM) tdonohue: So, yes, I'll admit there are some risks to using the AWS Free Tier. Namely, the students/mentors would need to be responsible for ensuring they do not get charged by Amazon. DuraSpace wouldn't have any control over that, but again, we could reimburse you if you end up with charges during GSoC
(4:36:26 PM) bojans: we just need to make sure all alarms and related actions (shut down) are properly setup
(4:36:39 PM) bojans: I would suggest that menthors and students do it together
(4:36:57 PM) mdiggory: sounds like a good idea
(4:37:25 PM) bojans: I do not know now
(4:37:30 PM) bojans: what are requirements of other projects
(4:37:50 PM) bojans: but for our case I would make necessary with Vibhaj
(4:38:00 PM) bojans: to make sure it is working and usable for our purpose
(4:38:19 PM) bojans: for the case it is not possible to setup such instance, or use it
(4:38:44 PM) tdonohue: It would be a good learning experience in itself to have the mentors & students work together on this :) I'd recommend that we try to document the process on the Wiki somewhere (so that we can refer to it for other GSoCs, possibly)
(4:39:00 PM) bojans: i could provide one simple vs instance on some of openvz servers i am workign with.. in the case community approves of course (without any obligations etc)
(4:39:10 PM) bojans: yes good idea too
(4:39:38 PM) bojans: so
(4:39:46 PM) bojans: if everyone agrees
(4:39:51 PM) bojans: or do not have other ideas :)
(4:40:05 PM) bojans: I would contact Vibhaj further for this work
(4:40:21 PM) bojans: and we would setup this aws instance and prepare basic documentation for other projects interested
(4:40:38 PM) tdonohue: I will also mention, the only other option here is that DuraSpace could create a GSoC Server in the *DuraSpace AWS account*. However, we would have to pay for that (will not be free), so there would be limitations on that server
(4:41:31 PM) mdiggory: what we really need is the image in the list of aws images that can be shared for spawning the instances
(4:41:52 PM) robertqin: hi sorry to interrupt
(4:42:05 PM) robertqin: but could i clarify more on this AWS Free account ?
(4:42:12 PM) tdonohue: mdiggory : currently we don't have an AWS image with DSpace on it. But, we should create one (for ease of spawning instances, etc)
(4:42:24 PM) tdonohue: sure, go ahead robertqin
(4:43:07 PM) robertqin: the purpose is demo-ing our projects?
(4:43:29 PM) robertqin: by using some amazon EC2 Micro Instance?
(4:44:04 PM) robertqin: i just like to know how it ties in to my current project
(4:44:26 PM) tdonohue: robertqin : Yea, actually the reason for this idea is that Vibhaj's project (New UI on RESTFul services) wanted a way to make a public demo available
(4:45:02 PM) tdonohue: robertqin: So, it'd be an *option* for other projects. But, it would not be required. So, each project could decide whether they want to have a public demo on an EC2 instance, or not.
(4:45:15 PM) robertqin: ah i understand
(4:45:21 PM) robertqin: okay thanks tim!
(4:45:28 PM) tdonohue: you are welcome
(4:45:40 PM) robertqin: because it seems my current tasks on my webmvc seems to tuned towards jspui rewrite
(4:45:59 PM) bojans left the room (quit: Ping timeout: 244 seconds).
(4:45:59 PM) robertqin: so i'm not too sure if that additional resources is needed for a public demo
(4:46:17 PM) tdonohue: robertqin -- yea, it may not be as necessary for all projects.
(4:46:20 PM) robertqin: might be something i have to clarify with graham and peter
(4:46:24 PM) robertqin: okay noted
(4:46:26 PM) robertqin: thanks !
(4:47:05 PM) mdiggory: the basic demo server would have tomcat / postgres / a basic install of trunk and a few dozen items already in it
(4:47:23 PM) mdiggory: that would also mean needing java, maven and ant
(4:47:24 PM) bojans [~Bojmen@62.68.103.161] entered the room.
(4:47:40 PM) tdonohue: right, mdiggory. Unfortunately, we don't have an image with all of that on it
(4:47:41 PM) mdiggory: for bojans sake
(4:47:42 PM) mdiggory: mdiggory: the basic demo server would have tomcat / postgres / a basic install of trunk and a few dozen items already in it
(4:47:42 PM) mdiggory: [2:47pm] mdiggory: that would also mean needing java, maven and ant
(4:47:51 PM) bojans: lost connectivity
(4:48:13 PM) bojans: ok
(4:49:16 PM) tdonohue: so, if we wanted a reusable "image" with DSpace pre-installed, we would need someone to create that. We could always export some test items from the demo.dspace.org server for that image
(4:49:53 PM) bojans: ok we could take a look at this
(4:49:59 PM) bojans: if i understood you correctly
(4:50:14 PM) bojans: it is necessary for someone to prepare a basic dspace install incl maven ant etc
(4:50:22 PM) bojans: import items from other instance
(4:50:33 PM) bojans: and save it as an aws importable vs instance?
(4:50:48 PM) tdonohue: exactly.
(4:51:00 PM) bojans: ok i could handle taht
(4:51:01 PM) bojans: that
(4:51:46 PM) tdonohue: sounds good to me then. If there's anything else that come up, email the list obviously and we can try to help out
(4:52:18 PM) bojans: ok
(4:52:49 PM) tdonohue: Anything else we want to discuss around GSoC today? Or any other important updates? (I'll note, I unfortunately have to leave in about 10 mins, but obviously the discussion can continue after that as needed)
(4:54:20 PM) bojans: seems there is nothing else to discuss
(4:54:48 PM) tdonohue: I guess not! Well, if anything else comes up, everyone should obviously feel free to bring it to the mailing list!
(4:54:57 PM) tdonohue: Have a good week everyone!
(4:55:16 PM) gaurav_kl: yeah.I have a few updates/issues regarding my project.
(4:55:36 PM) gaurav_kl: so I I am currnely in the process of making admin UI
(4:56:36 PM) gaurav_kl: I wanted to ask if there is a way of debugging in the process.
(4:57:28 PM) gaurav_kl: i mean with the tomcat running
(4:58:30 PM) tdonohue: what sort of debugging are you talking about, gaurav_kl?
(4:59:27 PM) gaurav_kl: i meant like putting break-point in the JS code of XMLUI
(5:00:02 PM) gaurav_kl: I tried using firebug
(5:00:43 PM) gaurav_kl: but could not succedd..so like I want to test if my code is reaching a particular fundtion in admininstrtive.js
(5:01:13 PM) gaurav_kl: on clicking a link.
(5:01:16 PM) tdonohue: so, you mean the actual Javascript processing code that's in the XMLUI? I think that part is actually a bit hard to debug (though I think you can add in logging there as basic debugging). But, maybe scottatm has some hints/tips?
(5:01:58 PM) gaurav_kl: yeah.I meant that.
(5:02:00 PM) robertqin left the room.
(5:02:06 PM) scottatm: Yeah, the javascript in the XMLUI flow scripts is a pain to write.... it's best to keep it just as simple as possible.
(5:02:26 PM) scottatm: You can using logging, but I don't believe you can step through it in a debugger.
(5:02:40 PM) gaurav_kl: ok.
(5:02:55 PM) scottatm: Push out almost all logic to java land, just have the flow of the next page be done in the flowscripts.
(5:03:18 PM) gaurav_kl: ok.
(5:04:11 PM) tdonohue: yea, I think scottatm is right. The Javascript flow scripts don't like to obey debuggers. But, I know you can use a debugger in other areas of the code (normal Java code, that is). There are some hints on enabling debugging in many of the major IDEs on: https://wiki.duraspace.org/display/DSPACE/Developer+Guidelines+and+Tools
(5:04:12 PM) kompewter: [ Developer Guidelines and Tools - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Developer+Guidelines+and+Tools
(5:05:00 PM) tdonohue: (you have to go to the page of the IDE you are using -- most of them talk about how to debug Dspace using that IDE.)
(5:05:05 PM) gaurav_kl: so for IDEA i am having the free version which I dont think has tomcat integration
(5:05:27 PM) gaurav_kl: will I need the advanced verdion to debug my JAVA code.
(5:06:06 PM) tdonohue: I'm actually not sure, as I don't use IDEA (I use NetBeans). I think mdiggory uses IDEA though, if I remember correctly
(5:06:25 PM) bojans: is there possibility to get an opensource edition of idea through dspace?
(5:06:32 PM) bojans: they give out free licences to opensource projects
(5:06:49 PM) bojans: ofcourse, if the required option is supported in os edition
(5:07:00 PM) tdonohue: we do have an open source license for IDEA actually. I forgot about that.
(5:07:27 PM) mdiggory: yes, we debug "around" the flowscripts... its difficult to do so in them
(5:08:00 PM) mdiggory: Ideally keep your business logic out of the flowscript and just use it to pass state and control
(5:08:24 PM) mdiggory: as scottatm says above
(5:08:45 PM) tdonohue: gaurav_kl: I'll send you the open source license for IDEA that DuraSpace has. All DSpace Committers have access to that, and you can use it for GSoC.
(5:08:58 PM) mdiggory: wish we had java flow with continuations instead of javascript
(5:09:38 PM) gaurav_kl: ok.thanks tim. mdiggory:how can i do normal java debugging with idea
(5:09:55 PM) tdonohue: mdiggory: yea, I'm not a fan of the javascript flow either, to be honest. I'd love it if someone redid it some day
(5:09:58 PM) mdiggory: a complete tangent.... http://mvnrepository.com/artifact/cocoon/cocoon-javaflow
(5:09:58 PM) kompewter: [ Maven Repository: cocoon » cocoon-javaflow ] - http://mvnrepository.com/artifact/cocoon/cocoon-javaflow
(5:10:58 PM) mdiggory: gaurav_kl: setup your tomcat runner in IDEA to start xmlui and solr, but instead start with "debug" instead "run"
(5:11:24 PM) gaurav_kl: ok
(5:11:26 PM) scottatm: I very much wanted javaflow when writing the XMLUI.... it just didn't work back then.
(5:11:58 PM) mdiggory: http://www.jetbrains.com/idea/webhelp/run-debug-configuration-tomcat.html
(5:11:58 PM) kompewter: [ Run/Debug Configuration: Tomcat ] - http://www.jetbrains.com/idea/webhelp/run-debug-configuration-tomcat.html
(5:12:50 PM) gaurav_kl: ok.thanks
(5:13:40 PM) tdonohue: I unfortunately have to head out now. But, feel free to continue GSoC discussion, if there's any other updates or questions...
(5:13:46 PM) hpottinger [d86a33b5@gateway/web/freenode/ip.216.106.51.181] entered the room.

These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.