Timestamps are in GMT/BST.
[1:29] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[2:06] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[2:17] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: No route to host)
[2:17] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[2:27] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[3:13] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[3:16] * snail (~yeatesst@130.195.179.39) has joined #duraspace
[3:17] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Ping timeout: 240 seconds)
[6:43] -wolfe.freenode.net- *** Looking up your hostname...
[6:43] -wolfe.freenode.net- *** Checking Ident
[6:43] -wolfe.freenode.net- *** Found your hostname
[6:44] -wolfe.freenode.net- *** No Ident response
[6:44] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:44] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:44] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:42] * elschlomo (~fas@HSI-KBW-078-042-098-211.hsi3.kabel-badenwuerttemberg.de) Quit (Quit: Leaving)
[12:55] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:05] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[15:11] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Remote host closed the connection)
[15:40] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[17:41] * eddies (~eddies@68.65.169.172) has joined #duraspace
[17:41] * eddies (~eddies@68.65.169.172) Quit (Changing host)
[17:41] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[18:38] * eddies1 (~eddies@68.65.169.168) has joined #duraspace
[18:38] * eddies1 (~eddies@68.65.169.168) Quit (Changing host)
[18:38] * eddies1 (~eddies@unaffiliated/eddies) has joined #duraspace
[18:40] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 252 seconds)
[19:52] <tdonohue> Hi all, just a friendly reminder that our DSpace Developers Meeting starts here at the top of the hour: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-12-07
[19:52] <kompewter> [ DevMtg 2011-12-07 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-12-07
[19:56] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:00] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> Hi all. it's DSpace Developer Meeting time!
[20:00] <tdonohue> as usual, we'll kick things off with a JIRA review.
[20:01] <tdonohue> here's our list of tickets left needing review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-902+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-902 ] - [#DS-902] Offer Item Mapping as a feature on "Edit Item" instead of only on Collections - DuraSpace JIRA
[20:01] <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-902+ORDER+BY+key+ASC
[20:01] <tdonohue> today we start with DS-902
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-902 ] - [#DS-902] Offer Item Mapping as a feature on "Edit Item" instead of only on Collections - DuraSpace JIRA
[20:01] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:02] * JoeDeVries (~jdevries@lib-pclax122.lib.utexas.edu) has joined #duraspace
[20:02] <tdonohue> any comments on DS-902? Looks as though aschweer may have some code that could help with this
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-902 ] - [#DS-902] Offer Item Mapping as a feature on "Edit Item" instead of only on Collections - DuraSpace JIRA
[20:03] <mhwood> Seems sensible.
[20:04] <tdonohue> yes, it'd get a +1 to me too. I think mapping should be available under "edit item" as well
[20:04] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[20:04] <KevinVdV> Well I'm always willing to create the UI for it
[20:05] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:05] <KevinVdV> But cannot promise to get it done for DSpace 1.8.
[20:05] <KevinVdV> 1
[20:05] <tdonohue> ok, we'll move on for now. Ds-902 summary: some support, seems sensible. Just needs a volunteer & code (aschweer's comment implies she may have something here)
[20:06] <tdonohue> KevinVdV -- yea, we're not trying to schedule these for 1.8.1 -- just doing a general review to see if we like the idea and/or can find volunteers to look at it more
[20:06] <KevinVdV> I'll take it then
[20:06] <tdonohue> KevinVdV -- feel free to claim it then! thanks.
[20:07] <tdonohue> ok, next up: DS-908
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-908 ] - [#DS-908] Embargo Overhaul: Utilize ResourcePolicy Start and Stop datestamps for enforcing embargo in DSpace - DuraSpace JIRA
[20:07] <tdonohue> oh, wait. looks like a placeholder for larger work. Any brief comments on Ds-908?
[20:07] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:09] <tdonohue> I like the general idea of Ds-908, but we'd just need to figure out a way to implement and move existing embargoes forward.
[20:09] <tdonohue> ok, since this is a placeholder, we'll just move on for now...
[20:09] <tdonohue> next, DS-909
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-909 ] - [#DS-909] Collection DEFAULT_ITEM_READ and DEFAULT_BITSTREAM_READ handling - DuraSpace JIRA
[20:10] <tdonohue> not sure I understand this one?
[20:12] <mhwood> Sounds like two issues: collection UI is too simple; display of access restrictions is broken.
[20:12] <tdonohue> should we split this apart & describe them better then?
[20:13] <mhwood> Collection UI can't adjust default READ and WRITE separately, but other UI can, and the result can't be show in Collection.
[20:14] <mhwood> Maybe what's needed is a simple way to put a widget on a page which means "take me to Rights Management, focused on this object."
[20:15] <mhwood> And a widget on the RM page meaning, "take me back where I came from."
[20:17] <tdonohue> I like the general idea. Though I wonder if a "simple fix" is to just duplicate a Collection's "Default read access" setting under "Assign Roles" so that it's "Default Item read access" and "Default Bitstream read access"?
[20:17] <mhwood> Hmmm. "UI too simple" really covers both, though. From the description, there just aren't enough widgets on the Collection page to express the rights situation.
[20:18] <mhwood> Yeah, that sounds like a good quick fix. Rights needs an extensive rethink at some point (see previous issue) but this will at least avoid confusing people so much.
[20:19] <ablemann> just want to chime in with a +1 for Ds-908. crontabs for checking dates complicates installs and creates situations that are inconsistent.
[20:19] <tdonohue> yea, it looks like the "Assign Roles" page just needs to have a widget that covers everything you can do on the "Edit Authorization Policies directly" page.
[20:19] <mdiggory> Ok this is where I come in and comment about the the "Assign Roles" Page being a poor design...
[20:19] <tdonohue> feel free to redesign it ;) I agree it's not the prettiest nor easiest to use.
[20:20] <mdiggory> the Role and its context is the Resource Policy being added to the Collection, just like all the others...
[20:20] <mdiggory> seems like things would be alot more intuitive if you had the desription and usage associated with the policy and its view rather than hardcoded into a hacky summary view page
[20:21] <mdiggory> plus these summary view pages like "Assign Roles" are non-extensible
[20:22] <tdonohue> If anyone has some ideas on how best to redesign this "Assign Roles" page, I'd be all in favor of someone submitting a mockup. I think we've just been "patching" it cause we haven't figured out a different way to display this info
[20:23] <tdonohue> (i.e. if anyone is interested, feel free to do a mockup of how this could look. Then we could find folks to try and rebuild it)
[20:24] <mdiggory> I hear ya
[20:24] <hpottinger> I have an internal ticket to look at changing the wildcard policy admin tool, which is kinda sorta related to all this
[20:24] <tdonohue> ok. we're running long here on just JIRA reviews. So, I'd suggest we wrap up discussion of Ds-909 and minimally post this chat discussion as a comment.
[20:25] <tdonohue> hpottinger -- yes, sounds related. If you find yourself wanting to do some redesign/mockups, let us know (or just do it and submit your ideas back)
[20:25] <mdiggory> tdonohue: I like the general idea. Though I wonder if a "simple fix" is to just duplicate a Collection's "Default read access" setting under "Assign Roles" so that it's "Default Item read access" and "Default Bitstream read access"? <--- seems sufficent for the moment...
[20:26] <hpottinger> marking DS-908 as related on my internal ticket
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-908 ] - [#DS-908] Embargo Overhaul: Utilize ResourcePolicy Start and Stop datestamps for enforcing embargo in DSpace - DuraSpace JIRA
[20:26] <tdonohue> hpottinger -- it's Ds-909, fyi ;)
[20:26] <hpottinger> doh, 909, thanks, kompewter
[20:26] <kompewter> hpottinger: You're welcome.
[20:26] <hpottinger> and tdonohue
[20:26] <tdonohue> ok. moving on for now. next up, updates on DSpace 1.8.1 upcoming release
[20:27] <tdonohue> any updates from anyone on 1.8.1? (ping robint)
[20:27] <mdiggory> Yes, we use this elsewhere and I think we may be able to pickup fixing timestamp capabilities
[20:27] <robint> Hello !
[20:27] <mdiggory> this relates to proper use of resource policies and the lack of ability to use what is actually implemented in Resource Policy
[20:27] <tdonohue> hi robin :)
[20:27] <mdiggory> IE timestamp ranges.
[20:28] <robint> There are only two 1.8.1 issues still open
[20:28] <mdiggory> recent work we did actually started using this to enforce access properly
[20:28] <robint> DS-1076
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-1076 ] - [#DS-1076] Visualisation of static pages is broken in 1.8 - DuraSpace JIRA
[20:28] <robint> and DS1082
[20:28] <robint> DS-1082
[20:28] <kompewter> [ https://jira.duraspace.org/browse/DS-1082 ] - [#DS-1082] Invalid embargo causes item archival to crash. - DuraSpace JIRA
[20:29] <tdonohue> looks like Ds-1076 is assigned to KevinVdV, and Ds-1082 is PeterDietz. Any updates guys on these? Do you need some feedback or help?
[20:30] <KevinVdV> Well I could use some opinions on Ds- 1082
[20:30] <tdonohue> err. other way around...Ds-1076 is PeterDietz, and Ds-1082 is KevinVdV
[20:30] <KevinVdV> Richard Rodgers argued that a default embargo might be in order
[20:30] <KevinVdV> Wondering what you guys think about it
[20:30] <tdonohue> KevinVdV: are you looking for opinions on the patch?
[20:30] <tdonohue> oh, I see the discussion now
[20:30] <KevinVdV> Yes since it probably isn't the best way
[20:31] <KevinVdV> & I do see & agree with Richard
[20:33] <PeterDietz> hi all, just arriving
[20:33] <tdonohue> hmmm... to me it seems like a simple fix could be for the UI to do some simple date validation on the embargo date?
[20:34] <KevinVdV> But what if the item remains in the workflow a bit long ?
[20:34] <KevinVdV> & the embargo date is passed that way
[20:34] <mhwood> The UI can't do it without help from the embargo code, since the format is so general.
[20:34] <mhwood> IIRC
[20:34] <tdonohue> ok, yea, I can see that point KevinVdV
[20:35] <tdonohue> I admit, I don't know this area of the codebase very well at all -- just brainstorming
[20:35] <mhwood> It's coming back to me. The EmbargoLifter is pluggable, and you can put literally anything in the metadata field (which is also configurable) so long as it has meaning to the lifter.
[20:37] <mhwood> I agree that validation is in order, but the UI will have to call the embargo code to ask whether a given value makes sense.
[20:37] <hpottinger> oh, then the validation function goes on the lifter
[20:37] <tdonohue> another crazy brainstorm: is there any way to "rollback" from an item-install error. So, what I mean by that is that if an error happens during the "Item Install", you rollback to putting the item back into workflow/workspace and display an error on the UI / and log it too?
[20:38] <mhwood> I suppose there's no easy way to just reject an uninstallable item and move on?
[20:38] <KevinVdV> I have to say I am not a fan of just UI checking the embargo, because the time of entering the embargo differs from the time from item instal
[20:38] <KevinVdV> install
[20:38] <mhwood> "These objects could not be restored: type ID reason"
[20:40] <tdonohue> KevinVdV -- would it be possible to just "catch" this error in the UI though, and display a message (like mhwood suggests): "This object could not be installed: [reason]"
[20:40] <KevinVdV> I am willing to look into it
[20:40] <tdonohue> it's not really validating anything then -- it's just catching the error, and letting the person fix the issue before they hit "Submit" again
[20:41] <mhwood> Isn't the original issue about restoring an AIP?
[20:41] <tdonohue> mhwood? no, I think it's just submitting an item? DS-1082
[20:41] <kompewter> [ https://jira.duraspace.org/browse/DS-1082 ] - [#DS-1082] Invalid embargo causes item archival to crash. - DuraSpace JIRA
[20:42] <mhwood> OK, I was reading too much into the word "archived".
[20:42] <ablemann> if it's invalid does that mean that it's necessarily in the past? can you just call the lifter?
[20:43] <tdonohue> mhwood -- yea, in this case, by "archived" we really mean the item is "installed into the DSpace 'archive'"
[20:43] <KevinVdV> @ ablemann Well but if an embargo WAS in place, it must be there for a reason.
[20:44] <mhwood> OK, so the workflow code should just hand it back and say, "can't be installed, fix this:"
[20:44] <tdonohue> ablemann -- it looks like there are two cases. The date is invalid, or the date is in the past. In the latter case, the date may be "in the past" cause the item had to go through workflow review (and for some reason that review took longer than the initially set embargo period)
[20:44] <mhwood> It shouldn't throw an exception all the way up.
[20:45] <tdonohue> mhwood +1 yea, it should report "please fix this:" (in some way). It seems like that could happen from *either* workflow or just normal submission though (if in the normal submission process someone enters a bad/invalid date)
[20:45] <KevinVdV> I am also a fan of setting the embargo to infinite or something like that & sending an alert email to somebody
[20:46] <mhwood> I wonder why "embargo date already passed" is an error.
[20:46] <tdonohue> KevinVdV -- in my mind that's a good "backup". But, it'd be better to force the person to fix it immediately (as the person you email may not even know what the embargo really should be set to)
[20:47] <mhwood> Theoretically it may not be a date at all. You could have a lifter that reads a URL out of the metadata and makes a query to some publisher's site to ask if it's okay yet, or some such.
[20:48] <tdonohue> mhwood -- nice idea, but I don't think many publishers tell you in a machine-readable fashion how long the embargo needs to be ;)
[20:48] <mhwood> I was assuming that the response would be "yes/not yet".
[20:49] <tdonohue> ok. so, it sounds like the status of this bug is still a bit up-in-the-air. Do we wait on this? Do we just continue with 1.8.1 whether it includes Ds-1082 or not?
[20:49] <mhwood> My point is that the embargo code really is that general. The rest of DSpace doesn't know what the embargo setting means.
[20:50] <mhwood> "Throws an exception all the way up to the user" is a bug and could be fixed, I think.
[20:51] <robint> Daft question time - so the value doesn't have to be a date ?
[20:51] <robint> At least not a typical date format ?
[20:51] <mdiggory> +1 to fix it based on KevinVdV and RRodgers recs. suggest that there be a value for "forever" that is the safe default...
[20:52] <tdonohue> in the default embargo implementation, I think it does need to be a date, doesn't it?
[20:52] <mhwood> As I understand it, no. The lifter that comes with DSpace thinks it's a date. But another lifter could expect something different.
[20:52] <robint> Could just be text that i interpretable by the lifter ?
[20:52] <mdiggory> Yes, the non-date values are used to calculate the date.
[20:52] <robint> In that case is InstallItem wrong to assume it will be a date ?
[20:52] <mhwood> Uh, I think there's a lifter that understands things like "N month".
[20:53] <robint> Ah sorry, just read the code
[20:53] <mhwood> That's what I've been saying: InstallItem has to ask the configured embargo code whether the value maks sense.
[20:53] <robint> the lifter returns the date
[20:53] <mdiggory> (aside, this is why I'm recommending using Polices with ranges for embargo. these can be open ended... "Restrict" ResourcePolicy with no start/end date)
[20:54] <tdonohue> (aside as well -- I like the idea of using Policies for embargo -- we just need an implementation & a way to convert current embargoes to Policy-based embargoes)
[20:55] <tdonohue> ok. should we set this aside for now? Sounds like hopefully we can have something simple ready for 1.8.1
[20:55] <robint> +1 to suggested fix. Seems a pragmatic solution
[20:56] <mhwood> Is it a lot of work to just catch the exception, refuse to install, and tell the user "sorry, needs fixing"?
[20:56] <tdonohue> i'm fine with suggested fix. My only other idea was to just find a way to "catch" the error in the UI and tell the user to "fix the embargo date". But, either way is fine by me
[20:56] <hpottinger> +1 to the fix suggested on the ticket, and I really like the idea of policy-based embargo
[20:56] <KevinVdV> Well that depends if the UI is doing the item install & it isn't an item import script or something of the like
[20:57] <robint> Plus the metadata input screens don't currently allow for error messages
[20:57] <robint> They just check if something is present or not
[20:57] <tdonohue> for an item import script (or non-UI stuff), I actually don't care if it throws an exception to the user. As long as the exception is useful
[20:58] <tdonohue> robint -- you misunderstand. The error message would be displayed once the item is actually *finished/submitted*. So, as the item is being installed, if the error occurs, we could try and catch it and jump the user back to the end of the submission process
[20:58] <tdonohue> (admittedly, not sure if that's possible -- but that is the idea)
[20:58] <robint> ah ok
[20:59] <tdonohue> again, I think either approach is fine. But, we might want to do a quick investigation on whether it's possible to catch this error easily (if so, then it may be even easier to just jump the user back to the end of the submission process in the UI)
[21:00] <tdonohue> ok, should we move on to the other open issue: DS-1076 (we're already running over in time)
[21:00] <kompewter> [ https://jira.duraspace.org/browse/DS-1076 ] - [#DS-1076] Visualisation of static pages is broken in 1.8 - DuraSpace JIRA
[21:00] <KevinVdV> T.b.h. I don't know if I can find the time to get the UI stuff done for DSpace 1.8.1. .......
[21:02] <tdonohue> KevinVdV: so you think the "forever" embargo is much easier? if so, I'm ok with it. I just wasn't sure it actually was easier. Or, the other option is to just delay DS-1082 until 1.8.2 (if we have one)
[21:02] <kompewter> [ https://jira.duraspace.org/browse/DS-1082 ] - [#DS-1082] Invalid embargo causes item archival to crash. - DuraSpace JIRA
[21:04] <robint> Looks like 1082 still needs picked up
[21:04] <robint> Doh! 1076
[21:04] <tdonohue> ok, before we talk about Ds-1076, I'm going to sidetrack this discussion a bit (since I know some folks will need to leave soonish). This is my *last* developer meeting until the week of Jan 9 (I'm on leave until then).
[21:05] <tdonohue> So, one question to ask why you are all still here: Do any of you want to take on the role of leading these meetings? (Or even rotate that role amongst some of you?)
[21:05] <tdonohue> Alternatively, I can ask bradm if he'd be willing to come back for a while and help lead/organize meetings in coming weeks
[21:06] <robint> I would do next weeks
[21:06] <tdonohue> (I just wanted to make sure that we had a plan for coming weeks -- as I'm going to be 100% offline starting Dec 14 until at least Jan 9)
[21:06] <mhwood> I can take a week.
[21:07] <mhwood> Do we feel that there are any weeks when attendance would be unproductively small?
[21:07] <tdonohue> ok, so do you all want to organize it amongst yourselves then? there's 4 weeks: 12/14, 12/21, 12/28, 1/4
[21:08] <tdonohue> I'm guessing the meeting on 12/28 may be "unproductively small" (we tend to not really meet between Xmas and New Years most years)
[21:09] <robint> If noone objects I'll do next week and then pass the baton on to whoever would like to do the following week ?
[21:09] <robint> and so on...
[21:09] <mhwood> If we're going to meet on 12/21 I could take that one. I may not be available on 1/4 as we have "Organizational Week" the first week of the year -- staff meetings and workshops for several days.
[21:09] <tdonohue> sounds good to me, robint
[21:09] <robint> mhwood: that sounds fine
[21:10] <tdonohue> "pass the baton" sounds like a good plan. If any "big decisions" happen, just be sure to send a note along to dspace-commit or similar
[21:11] <tdonohue> ok. so, should we move back to DS-1076, which I think is assigned to PeterDietz? Any quick updates or help needed?
[21:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1076 ] - [#DS-1076] Visualisation of static pages is broken in 1.8 - DuraSpace JIRA
[21:12] <PeterDietz> When is 1.8.1 planned to be released?
[21:12] <robint> Its not fixed yet
[21:12] <tdonohue> it sounded like robint was hoping for mid-Dec? is that right
[21:12] <robint> I finish up at the end of next week so if its after thaat then someone else would need to do it
[21:13] <robint> Personally I think it would be worth doing a release at the end of next week with whatever is ready
[21:13] <tdonohue> (though if we really need to delay until Jan, that's fine really -- the amount of people who really want to install DSpace in mid-Dec is probably rather low)
[21:13] <robint> tdonohue: good point
[21:14] <tdonohue> That being said, I'd personally prefer to release next week as soon as we can though (as we've fixed some significant bugs/errors already, and we can always do a 1.8.2). But, I'll leave it up to all of you :)
[21:14] <robint> My vote is for a release late next week
[21:16] <tdonohue> So, PeterDietz -- any quick updates you'd like to share? Or is Ds-1076 not likely to be fixed until Jan?
[21:18] <PeterDietz> I'd vote to release next week. I'll look at this issue, try to get something this week ready for it. Does mdiggory have any code to send in as well?
[21:19] <tdonohue> PeterDietz -- IIRC, last week we determined that mdiggory's work was actually a new feature, and there may be a much more simplistic way to just do a quick fix for 1.8.1 (and leave bigger changes for the next major release)
[21:20] <tdonohue> you might want to check the discussion logs from last week's meeting
[21:20] <hpottinger> I can help with testing 1076 if needed
[21:20] <mhwood> I can test too.
[21:21] <mdiggory> right,
[21:21] <mhwood> Wasn't the other plan to just make a servlet that has a list of places to look, and map it from one or more places in URLspace?
[21:21] <mdiggory> so, i'm trying to understand better... none of Ds1076 code is actually in 1.8.0?
[21:22] <mdiggory> its all here... https://wiki.duraspace.org/display/DSPACE/Manakin+theme+tutorial#Manakinthemetutorial-Addingstaticpages
[21:22] <kompewter> [ Manakin theme tutorial - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Manakin+theme+tutorial#Manakinthemetutorial-Addingstaticpages
[21:23] <mdiggory> If I understand correctly there is no "static" page solution in 1.8.0. just a fix that breaks this demonstration code.
[21:24] <mhwood> That was my understanding. People have found ways to hack statics in, but they were never designed in.
[21:24] <mdiggory> seems more like the demonstration code needs improvement, not changes to DSpace 1.8.1
[21:24] <tdonohue> If I'm reading it correctly, Ds-1076 actually says 1.8.0 *breaks* the "static" page demo code that used to work in 1.7.x
[21:25] <mdiggory> although, yes I agree having a better static solution inplace out of the box is highly sought
[21:25] <tdonohue> the description of Ds-1076 actually says the demo code no longer works in 1.8.0 because it was accidentally broken by the fix to DS-768
[21:25] <kompewter> [ https://jira.duraspace.org/browse/DS-768 ] - [#DS-768] All XMLUI Error Pages respond with 200 OK, instead of 404 Not Found - DuraSpace JIRA
[21:25] <mhwood> Yes.
[21:26] <mdiggory> thats because the demo code actually utilized the "bug" to accomplish what it does ;-)
[21:26] <tdonohue> ok. well, if there's a better way to do static pages in 1.8.0, then we could just change the docs. (I admit, I don't know this area well)
[21:27] <mhwood> Would fixing the demo code actually be quicker than writing something which implements: if you want to display a static page, put it *here* and link to it *here*.
[21:27] <mdiggory> Actually the solution is to write a better "About.java"
[21:28] <mdiggory> as was discussed last time.
[21:28] <mdiggory> About.java --> rename to "StaticPage.java"
[21:28] <mdiggory> add code that looks for file in static directory
[21:28] <tdonohue> right -- this is the same discussion as last week :)
[21:28] <mdiggory> returns nothing otherwise
[21:28] <PeterDietz> That would be a new feature, not a bug fix.
[21:28] <robint> I've got to go. Cheers all
[21:29] <robint> And tdonohue: hope all goes well !
[21:29] <tdonohue> thanks robint :)
[21:29] <mdiggory> PeterDietz: its not even a new feature if someone just adds it to the tutorial....
[21:29] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:29] <mhwood> I just wonder if the new feature wouldn't be quicker and easier than the fix.
[21:29] <mdiggory> Its an addon aspect for DSpace
[21:30] <mdiggory> someone can make a modules project for it. release it separately to maven, if folks want to use it, they just add the dependency to their xmlui
[21:31] <tdonohue> if the "new feature" is one class that is small/quick/easy/well tested, we could still let it slide. We just need approval of robint & a majority of us, as we really don't want to open the floodgates to new features.
[21:31] <tdonohue> (i.e. technically, this "new feature" is actually still fixing a bug that exists. So, I'd be OK with it as long as this doesn't snowball into something larger)
[21:32] <hpottinger> I like the module option idea, but just rolling it into 1.8.1 seems straightforward, too
[21:33] <tdonohue> I just vote for whatever seems "simplest". If that happens to be the "StaticPage.java" route, I'd be OK with it
[21:33] <KevinVdV> Need to run, sorry guys
[21:34] <mhwood> A whole aspect/template team just to blurt some .xhtml file to the browser seems like overkill. Did I misunderstand what we mean by "static"?
[21:34] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) Quit (Quit: KevinVdV)
[21:34] * tdonohue sorry we are going over by so much today -- I just didn't want to cut short these discussions. But, if you need to leave, obviously feel free!
[21:35] <tdonohue> +1 mhwood. I agree this shouldn't be a whole new aspect. Everything doesn't need it's own aspect, especially something this obvious. I'd bet most sites would want the ability to add static pages & expect this out-of-the-box.
[21:36] <hpottinger> mhwood, it seems like a lot of engineering to invoke, but on the plus side, cocoon will happily cache the heck out of that static file :-)
[21:36] <mhwood> The filesystem will already cache it.
[21:37] <mhwood> Cocoon caching, it seems to me, is for things created on the fly, identically, more than once.
[21:38] <tdonohue> ok, so PeterDietz and/or mdiggory -- do we have a direction/ideas for Ds-1076? Or is this still needing more thought/discussion? I'm not sure if you know which direction you plan to head with this or not
[21:38] <mhwood> If the file is going to go through the whole pipeline, then we'll need to specify what it can contain and how it is altered along the way out. I thought that "static page" meant "just ship this file with HTTP around it".
[21:39] <tdonohue> mhwood -- I have same understanding. My idea of "static page" is also "just ship this file with HTTP around it"
[21:39] <hpottinger> I think static in this case means "static blob with my theme wrapped around it"
[21:41] <PeterDietz> hpottinger's view point is how I interpret this as well
[21:41] <mhwood> So that's why we have so many ideas bumping into each other.
[21:41] <tdonohue> oh, ok. I see. Yea, that makes sense hpottinger
[21:41] * cbeer (~cbeer@198.147.175.203) Quit (Ping timeout: 252 seconds)
[21:42] <tdonohue> so, do we have a direction here that makes sense to you, PeterDietz (since you are currently assigned to Ds-1076)?
[21:43] <PeterDietz> I've got in my head how it is expected to function. I'm just running thinking about what implementation will get us there.
[21:43] <PeterDietz> So, I would say I have what I need.
[21:43] <hpottinger> and two volunteers for testing :-)
[21:44] <mhwood> Yes.
[21:44] * eddies1 (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[21:45] * eddies (~eddies@68.65.169.197) has joined #duraspace
[21:45] * eddies (~eddies@68.65.169.197) Quit (Changing host)
[21:45] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[21:45] <tdonohue> ok, sounds good.
[21:45] <PeterDietz> So, demo.dspace.org/xmlui/some-new-page is going to be caught by Kim's Fresh 404's, hack#1 is assuming it can intercept that DRI, and replace the title and add some html body.
[21:45] <mhwood> May I suggest calling it "external static content" if it's going to be wrapped in DHTML.
[21:47] <PeterDietz> I think the bare-minimum changes for end-site is going to be to add some map:match pattern for their various static url's. Then they can mess with the xsl to add the body/content. Whether that be embedded content in the xsl, or external-static-content from some-static-page.xhtml in the static directory
[21:48] <PeterDietz> I'll get to coding then
[21:48] <mhwood> Thank you!
[21:52] <tdonohue> sounds good.
[21:53] <tdonohue> fyi -- just cause I had a vague memory of static pages in the past, I recalled we actually already have a way to display fully static HTML (not with the theme wrapped around): https://jira.duraspace.org/browse/DS-97 (src/main/webapp/static/), e.g. robots.txt
[21:53] <kompewter> [ https://jira.duraspace.org/browse/DS-97 ] - [#DS-97] XMLUI does not come with a robots.txt out-of-the-box. It also does not provide suggestions for loading global static content. - DuraSpace JIRA
[21:53] <kompewter> [ [#DS-97] XMLUI does not come with a robots.txt out-of-the-box. It also does not provide suggestions for loading global static content. - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-97
[21:54] <tdonohue> (I realize this is not the same type of "static" pages we are now talking about though)
[21:54] <tdonohue> in any case, we'll let you get to it PeterDietz.
[21:54] <tdonohue> We can close up this meeting (nearly an hour late). I'll stick around in case anything else comes up
[21:55] <tdonohue> have a great holidays all! I'll talk to you all in January, when I return from leave around Jan 9.
[21:58] <hpottinger> grats again, tdonohue, enjoy your new baby!
[21:59] <tdonohue> thanks...very soon very soon :)
[22:00] <hpottinger> book recommendation: anything by Dr. Sears, but the Baby Book is the best
[22:03] <tdonohue> cool. thanks for the recommendations. I've already read a few such books, and taken some classes. So, we're prepared as we'll ever be.
[22:03] <tdonohue> :)
[22:04] <mhwood> 'bye all, and Happy Holidays.
[22:04] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:24] * bradmc (~bradmc@68.65.169.208) has joined #duraspace
[22:25] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[23:09] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.