Timestamps are in GMT/BST.
[6:54] -zelazny.freenode.net- *** Looking up your hostname...
[6:54] -zelazny.freenode.net- *** Checking Ident
[6:54] -zelazny.freenode.net- *** Found your hostname
[6:55] -zelazny.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
[13:05] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:07] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[15:12] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Ping timeout: 240 seconds)
[15:34] * PeterDietz-alt (~dspace@sul272sandbox.lib.ohio-state.edu) Quit (*.net *.split)
[15:34] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (*.net *.split)
[15:34] * scottatm (~scottatm@voyager108.evans.tamu.edu) Quit (*.net *.split)
[15:38] * ablemann (~alexleman@lemanal.new.xen.prgmr.com) Quit (Ping timeout: 244 seconds)
[16:06] * PeterDietz-alt (~dspace@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[16:06] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[16:06] * scottatm (~scottatm@voyager108.evans.tamu.edu) has joined #duraspace
[16:06] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[16:06] * ablemann (~alexleman@lemanal.new.xen.prgmr.com) has joined #duraspace
[19:48] <tdonohue> Hi all, reminder we have our weekly DSpace Developer Meeting here in a little over 10mins : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-01-25
[19:55] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) has joined #duraspace
[19:59] * PeterDietz (~peterdiet@128.146.173.59) has joined #duraspace
[20:00] * PeterDietz-alt (~dspace@sul272sandbox.lib.ohio-state.edu) Quit (Quit: Leaving)
[20:00] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:00] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[20:00] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Developers Meeting. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-01-25
[20:00] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:01] <tdonohue> small crowd again this week. everyone must be slacking! :)
[20:01] <PeterDietz> Hi
[20:01] <PeterDietz> ...or busy testing git
[20:01] <tdonohue> we can only hope, PeterDietz
[20:02] <tdonohue> Ok, we'll get started with some JIRA reviews: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-929+ORDER+BY+key+ASC
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-929 ] - [#DS-929] Crisp thumbnails - DuraSpace JIRA
[20:02] <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-929+ORDER+BY+key+ASC
[20:02] <tdonohue> first up, DS-929
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-929 ] - [#DS-929] Crisp thumbnails - DuraSpace JIRA
[20:02] * hpottinger (~hpottinge@mu-108022.vpn.missouri.edu) has joined #duraspace
[20:03] <PeterDietz> man.. look at those nice crisp thumbnails
[20:04] <tdonohue> any thoughts on this idea to integrate ImageMagick for thumbnails (Ds-929). any volunteers to investigate it?
[20:05] <tdonohue> seems like a reasonable idea to me, though I have no experience with ImageMagick. It is nice that Cambridge has provided the code they use (see link in comments)
[20:05] <PeterDietz> These types of improvements on our (OSU) radar, however, not in next 3-6 months
[20:05] * JoseBlanco (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) has joined #duraspace
[20:05] <PeterDietz> I do like that there is code... could make it much less of a burden
[20:06] <PeterDietz> We, the DSpace maintainers, what functionality would we like to see for disseminators?
[20:06] <tdonohue> Ok, so it sounds like at least a few of us feel this is a good idea. Just needs a volunteer to tackle Ds-929
[20:07] <KevinVdV> Seems interesting I am willing to look into it if nobody else is willing ?
[20:07] <PeterDietz> i.e. would you prefer to have DSpace know how to create renditions (derivative versions for display), or to just hook up a service like imageMagick that might be another webapp, that just does one thing
[20:08] <tdonohue> KevinVdV : feel free to claim it if you'd like. You can always unassign yourself if you don't get to it
[20:08] <hpottinger> PeterDietz: DSpace can already create renditions, yes?
[20:08] <KevinVdV> Will do, if I find the time I will take a closer look (unless Peter Dietz objects & wants it for himself ?)
[20:09] <tdonohue> PeterDietz -- I'd be fine either way to be honest. I think there's a place for both options (i.e. allow DSpace to integrate with several thumbnail-generation solutions, based on your needs/desires)
[20:09] <PeterDietz> DSpace can do renditions, mostly just extracting text, or creating thumbnail images (from JPEG source, or of PDFs)
[20:10] <tdonohue> ok, sounds like discussion has stopped. Moving along to: DS-932
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-932 ] - [#DS-932] Retrieval/lookuap of objects based on their Handle - DuraSpace JIRA
[20:11] <PeterDietz> REST
[20:11] <tdonohue> +1 to this idea. This seems like a basic feature that should be in REST API
[20:11] <PeterDietz> Does REST have its own JIRA, or is it a component of DS
[20:12] <tdonohue> it's currently a component of DS. It doesn't have its own JIRA
[20:12] <PeterDietz> I'd say +1 to dS-932, rest should have good capabilities
[20:13] <tdonohue> ok, so sounds like there's support for the idea. Ds-932 just needs a developer/volunteer to start working on it.
[20:14] <tdonohue> we'll move along to DS-933
[20:14] <kompewter> [ https://jira.duraspace.org/browse/DS-933 ] - [#DS-933] Sorting and pagination issue - DuraSpace JIRA
[20:14] <tdonohue> another REST issue
[20:15] <tdonohue> I don't have enough experience with REST to know if this is an issue (assuming it must be, since Bojan put it in)
[20:16] <PeterDietz> He's maintainer, I image him dumping several issues is so whoever works on rest can do them all.
[20:16] <PeterDietz> s/image/imagine/
[20:16] <kompewter> PeterDietz meant to say: He's maintainer, I imagine him dumping several issues is so whoever works on rest can do them all.
[20:16] <tdonohue> yep, I'd agree PeterDietz
[20:17] * JoseBlanco (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) Quit (Quit: Page closed)
[20:18] <tdonohue> So, I wonder if we should stop JIRA here for today. As this brings up a related question (not really on agenda though): Who amongst those in attendance have used the REST API?
[20:19] <tdonohue> and/or is there anyone interested in that area of DSpace? Or is it something that we just have "sitting around" right now
[20:19] <PeterDietz> I used it for a good 2 weeks several months ago.. It was fun, having to fix bugs made me stop using it
[20:20] <tdonohue> Is it an area of interest to you PeterDietz? Or were the bugs just too much?
[20:20] <PeterDietz> Its sitting around now.. There was a mailing list thread a month or so back, that some group used it, fixed lots of bugs, and wanted to contribute, but we haven't followed up on that
[20:21] <tdonohue> hmmm... I must've missed that thread.
[20:21] <hpottinger> I'm intending to play around with it, as it's a prerequisite for the Drupal DSpace module
[20:21] <PeterDietz> I'd love to have a REST API.. We hit a problem with xmlui caching, that was a blocker to upgrading to 1.7, so I wired up Rest, got the data i needed, and had xmlui do ajax requests for recent submissions.
[20:21] <PeterDietz> it worked
[20:22] <PeterDietz> I ended up fixing xmlui, and didn't _need_ rest. Plus rest, with inconsistent security, and potential to hang up the servlet container (tomcat), becomes a liability having on our production system
[20:22] <tdonohue> I'd also love to have a REST API, and it seems to be gaining some traction in some areas. I'm just wondering out loud how we go about "bringing it in" better (i.e. ramp up support a bit / improve on the buggy REST API that currently exists)
[20:23] <tdonohue> seems like REST API could be a great out-of-box "feature" of DSpace 3.0, if we can find folks interested in helping it along a bit.
[20:24] <PeterDietz> http://sourceforge.net/mailarchive/forum.php?thread_name=CAM4xwc6wmbkh92hBeZR1FJ5Fo1vhwA1pM8dpYUUDaO42iCsMew%40mail.gmail.com&forum_name=dspace-devel
[20:24] <kompewter> [ SourceForge.net: DSpace: dspace-devel ] - http://sourceforge.net/mailarchive/forum.php?thread_name=CAM4xwc6wmbkh92hBeZR1FJ5Fo1vhwA1pM8dpYUUDaO42iCsMew%40mail.gmail.com&forum_name=dspace-devel
[20:25] <PeterDietz> http://hedtek.com/2011/dspace-rest-api-testing/
[20:25] <kompewter> [ DSpace REST API testing ] - http://hedtek.com/2011/dspace-rest-api-testing/
[20:25] <PeterDietz> https://github.com/hedtek/dspace-rest
[20:25] <kompewter> [ hedtek/dspace-rest - GitHub ] - https://github.com/hedtek/dspace-rest
[20:27] <tdonohue> thanks for the links, PeterDietz. I must've completely missed this work & email thread. Would be good to pull that into REST API, as it sounds useful
[20:27] <tdonohue> maybe we need to create a JIRA ticket for that
[20:27] <PeterDietz> I think we'll run into our core-DSpace vs modules issue. Rest is currently a module. Ideally it should be/stay a module. But its not going to have as many hands on deck if its codebase is outside of coreDSpace
[20:28] <PeterDietz> To bridge hedtek's work into our/Bojan's rest code, we need to rebridge their histories together. Hedtek did a history-less clone
[20:29] <tdonohue> ugh. yea, I get what you are saying
[20:30] <PeterDietz> glueing two things together is doable. Not pain-free, but doable. I had planned to spearhead that one. However, I'm not sure if Bojan has looked at git at all. (sorry for making premature assumptions on code base future)
[20:31] <tdonohue> well, step #1 seems to be to get this project into JIRA, so that we can start discussions around what it may take, etc.
[20:31] <tdonohue> (and to hopefully bring Bojan in the loop, if he missed the thread)
[20:31] <PeterDietz> As is stands, I look at DSpace-REST, and say, "wow, so much promise, I wish it were more stable".. From hedtek's blog, it looks like they then built a test-suite, and worked many many bugs out.
[20:33] <tdonohue> PeterDietz -- would you be willing to enter this rebridge/merge project into JIRA (with links provided above). That way we can point Bojan at it, and find a volunteer to take it on (whether that's Bojan, yourself or someone else).
[20:33] <PeterDietz> I got an idea... What if we wired up demo.dspace to use the rest-api, so it could get more notice
[20:33] <tdonohue> it could also be used to start discussion as to whether REST API codebase could move to GitHub, so that folks like hedtek can more easily fork it and send pull requests
[20:34] <tdonohue> +1 to that idea (putting REST on demo.dspace.org). I just never have gotten around to that one. But, feel free to do ASAP if you have a few extra cycles. It'd make it much easier to play with REST
[20:34] <PeterDietz> ...and that would be just enough motivation for me to bridge the two code-bases
[20:35] <hpottinger> PeterDietz, if I can help out in any way with incorporating hedtek's work, I volunteer, this touches two of my favorite concerns (external UI support and testing)
[20:35] <PeterDietz> sidenote: I'd also like to put the dspace-webmvc code up their too
[20:35] <tdonohue> (Sidenote: The development of the 'dspace-replicate' module has now moved entirely to GitHub. I'm loving it so far)
[20:36] <tdonohue> (FYI the 'dspace-replicate' module is the DSpace Replication Task Suite: https://wiki.duraspace.org/display/DSPACE/ReplicationTaskSuite)
[20:36] <PeterDietz> .addpoint tdonohue
[20:36] <kompewter> tdonohue: +1/-0, 1
[20:37] <tdonohue> it's a shame kompewter doesn't just recognize "+1" as ".addpoint" :)
[20:38] <tdonohue> ok. in any case, it sounds like we have a few actions out of this REST discussion. (1) enter a JIRA task about the code merge, (2) start discussions about possibly moving REST to GitHub, (3) actually find someone to do the merge
[20:39] <tdonohue> PeterDietz, do you want to take the lead on action #1 (and even possibly #2). I'm all for trying to get all of these done in nearish future (just don't have the cycles myself right now)
[20:40] <tdonohue> (if you don't have time either, that's fine -- just thought I'd ask)
[20:40] <PeterDietz> I can (1) create a jira ticket about hedtek's contributions/etc.
[20:40] <PeterDietz> i can (2) email Bojan / list about moving project to github.
[20:41] <tdonohue> sounds great! thanks.
[20:41] <PeterDietz> I remember asking Bojan when were in Mountain View about git, and he hadn't looked into it. And was thinking "i know svn, i'll stay there".
[20:42] <tdonohue> yea, now might be a good time to ask again, especially now that we can point at other contributers on github (hedtek).
[20:42] <tdonohue> and I agree we should just start a thread on that on dspace-devel
[20:45] <tdonohue> Ok, going back to our Agenda, my only other thought here was to start discussing whether there are any "larger projects" we may want to investigate more for 3.0
[20:45] <tdonohue> ... and whether we want to start setting up a few Special Topic Meetings to see if we can get moving along (or find a few volunteers to start moving them along, even if it's a bit slow at first)
[20:46] <tdonohue> Obviously, as we have a long time until 3.0 (Fall/Winter 2012), now is the time to start thinking about if there's any larger projects we all feel are important to start to work towards (in the hopes they may be ready for 3.0)
[20:47] <tdonohue> a few large projects that I'm aware are getting lots of support include:
[20:47] <tdonohue> (1) Common Business Logic API -- trying to avoid/remove logic duplication between all our UIs
[20:48] <tdonohue> (2) Metadata improvements (subtopics: updating us to latest DC/DCMI schemas, Metadata on all objects, support for a few more metadata schemas) --> This has large support from DCAT it seems
[20:49] <tdonohue> so, my question is what do we feel are good "next steps" here? A special topic meeting (or two)? send a call for volunteers / team of devels?
[20:49] <tdonohue> (and are there any other large topics we really should look to tackle soon?)
[20:50] <hpottinger> An issue getting tracking in DCAT is the idea of embedded players and/or streaming servers.
[20:50] <hpottinger> https://wiki.duraspace.org/display/dsforum/DS-1021+Add+integration+with+an+online+document+viewer
[20:50] <kompewter> [ https://jira.duraspace.org/browse/DS-1021 ] - [#DS-1021] Add integration with an online document viewer (like flash based FlexPaper) - DuraSpace JIRA
[20:50] <kompewter> [ DS-1021 Add integration with an online document viewer - DCAT Discussion Forum - DuraSpace Wiki ] - https://wiki.duraspace.org/display/dsforum/DS-1021+Add+integration+with+an+online+document+viewer
[20:51] <tdonohue> hpottinger: yep, that's another I've heard would be nice.
[20:51] <tdonohue> plus, Ds-1021 would be a very nice "flashy" feature for DSpace 3.0, if we could find a volunteer or two
[20:52] <scottatm> DS-121 would be very nice.
[20:52] <kompewter> [ https://jira.duraspace.org/browse/DS-121 ] - [#DS-121] XMLUI Feedback form breaks with multiple hostnames - DuraSpace JIRA
[20:52] <scottatm> err 1021 :)
[20:52] <tdonohue> :) yea, I thought that was a typo
[20:53] <PeterDietz> I have a question about "i don't trust my content in the cloud". If your university's content repository (DSpace) houses the archive copy of a video, what is wrong about leveraging some type of curation-task auto-submit videos to YouTube, to facilitate streaming?
[20:54] <tdonohue> PeterDietz: what's the context around that question? not sure I understand?
[20:55] <PeterDietz> I was thinking document-streaming.
[20:55] <tdonohue> oh, well, I think it would be reasonable to auto-submit videos to YouTube, assuming they are *public* videos. The issue comes about when you may want to restrict access to just on-campus users (which I'm not sure something like YouTube would support)
[20:55] <PeterDietz> You house a copy of a pdf, image, audio, video. And DSpace can only serve binary content. If you use a fancy-streaming-service, then you can deliver all the bells/whistles to meet needs of presenting content well
[20:57] <hpottinger> tdonohue: +1 YouTube is OK for open-access materials, as any other cloud-based service
[20:57] <tdonohue> PeterDietz -- another issue is that there's a limit to the amount of content you often can push to a cloud-streaming-service (without having to pay money)
[20:58] <tdonohue> so, I see DS-1021 as basically saying that they want DSpace to support some simple "document-streaming" services out-of-the-box, if possible (though no mention of Video streaming here, just document viewing)
[20:58] <kompewter> [ https://jira.duraspace.org/browse/DS-1021 ] - [#DS-1021] Add integration with an online document viewer (like flash based FlexPaper) - DuraSpace JIRA
[20:59] <PeterDietz> hmm. I think @mire already offers document streaming
[20:59] <tdonohue> they do, but for a price :)
[20:59] <hpottinger> better/friendlier interface to large objects: page turning for PDFs/books, and tiling image viewer for large images
[21:00] <scottatm> I don't really care about streaming, it would just be nice to have a good page turner for DSpace.
[21:00] <PeterDietz> https://picasaweb.google.com/115522466408243604820/OSULibrariesDSpaceDesigns#5516829984952797698
[21:00] <kompewter> [ Picasa Web Albums - Peter Dietz - OSU Libraries... ] - https://picasaweb.google.com/115522466408243604820/OSULibrariesDSpaceDesigns#5516829984952797698
[21:00] <hpottinger> I'm tinkering around with a couple of things, Multivio for page turning and PanoJS for images
[21:01] <tdonohue> cool, hpottinger. are those both free/open source?
[21:01] <hpottinger> tdonohue, yep
[21:01] <tdonohue> PeterDietz: are you saying you already have a page turner at OSU?
[21:02] <tdonohue> hpottinger: cool, sounds like some good directions then.
[21:02] <hpottinger> Multivio is JS front end, back end is Ruby; PanoJS is all JS, requires a "pile of tiles" for each image
[21:04] * tdonohue notices we're running over time here. I'll stick around though to continue this discussion. If folks need to head out, feel free.
[21:05] <PeterDietz> The code for integrating the book-reader is in a state of dis-repair. https://github.com/osulibraries/xmlui-webapp/tree/master/themes/book-reader Our Repository Admin committee shot the book reader down, so we stopped developing it.
[21:05] <kompewter> [ themes/book-reader at master from osulibraries/xmlui-webapp - GitHub ] - https://github.com/osulibraries/xmlui-webapp/tree/master/themes/book-reader
[21:05] <tdonohue> PeterDietz -- browsing through your OSU DSpace pics, you all have a lot of nice features. We should convince you to try and send more code back, if you can ever find the time! :)
[21:06] <hpottinger> tdonohue: 1021 only mentions document streaming, but, obviously, the concerns are the same for any large object stored in DSpace
[21:06] <PeterDietz> I think if I had an espresso machine at home, and then didn't have to go to work anymore. I could figure out how to accomplish it.
[21:07] <tdonohue> +1 hpottinger -- I agree. we should look towards better "visualizations" of objects in DSpace in general. So, we should be free to extend beyond just the requirements of Ds-1021
[21:07] <mhwood> Sorry, just got back from nursing a sick SAN.
[21:07] <tdonohue> PeterDietz: haha :) Well, either that, or see if you can push it all up towards GitHub (if it isn't there already), and someone else who wants the feature can dig through it and pull out the "good parts"
[21:08] <tdonohue> mhwood: poor sick SAN. hope it's feeling better
[21:08] <mhwood> It was when we left.
[21:08] <mhwood> Anyway, I see people talking about "page turner" and I always think, "doesn't Adobe Reader already do that?"
[21:09] <PeterDietz> i have the same issue at the rest code. I moved OSU's code base to git way before I made the SVN-DSpace.org <-SYNC-> GitHub. So the code bases are disjoint, so they can't "merge". I have to figure out how to stitch it together.
[21:09] <hpottinger> mhwood: Adobe Reader doesn't do random seek until the entire object is downloaded
[21:09] <mhwood> Huh, I was sure I had seen it do that.
[21:10] <tdonohue> PeterDietz: ah, I see. Well, again, if someone else really wanted the feature, and the code is in GitHub, maybe they'd still be willing to help move some features back into main DSpace code.
[21:11] <tdonohue> mhwood: yea, I think hpottinger's right. You have to download the full object first with Adobe. The online page turners can be nice if you don't want to download a large file yet (or alternatively are accessing via a mobile device, which may or may not have good Adobe support)
[21:12] <hpottinger> mhwood, I'm pretty sure we've had this conversation before :-) I can look it up if you wish.
[21:12] <mhwood> Ah, that would be my memory acting up again.
[21:14] <tdonohue> PeterDietz: looking at your OSULibraries github account makes me realize we should encourage folks to stick their custom Themes up somewhere for sharing: https://github.com/osulibraries/xmlui-webapp/tree/master/themes
[21:14] <kompewter> [ themes at master from osulibraries/xmlui-webapp - GitHub ] - https://github.com/osulibraries/xmlui-webapp/tree/master/themes
[21:15] <tdonohue> would be great to have everyone post their themes up to GitHub somewhere, so that others can build from them & improve, etc
[21:16] <PeterDietz> thats where I was going with: https://github.com/DSpace/xmlui-webapp/network but only OSU, and SUNScholar jumped
[21:16] <kompewter> [ The xmlui-webapp Network - GitHub ] - https://github.com/DSpace/xmlui-webapp/network
[21:18] <tdonohue> aha, didn't realize that PeterDietz. Maybe it just needs some more publicity (and obviously be maintained more), to see if others would also jump eventually
[21:19] <tdonohue> just something to think about, assuming we do the GitHub jump. I like the idea of having a separate "repo" of themes that folks can fork & also request pulls back into. May be what we really neeed to move the out-of-the-box DSpace themes forward
[21:20] * PeterDietz is on the fence. But leans towards helan går. i.e. have a full fork of DSpace for *all* university customizations
[21:20] <PeterDietz> otherwise, I have to get in the habit of subtree splitting my themes etc
[21:20] <KevinVdV> I need to run guys, cya later
[21:20] <PeterDietz> later KevinVdV
[21:20] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) Quit (Quit: KevinVdV)
[21:21] <tdonohue> that would also be quite nice. Just thought that at the very least, more sharing of themes could help us all immediately share UI changes (and rapidly improve the UI)
[21:21] <scottatm> Patches are so much easier to deal with on git than svn.
[21:22] <scottatm> and like you allude to it allows for much more realistic workflows.
[21:22] <tdonohue> +1 scottatm
[21:24] <PeterDietz> I imagine that University of Finite Resources (aka UFR), will not be making dspace-api changes, but will only have ever customized dspace-xmlui-webapp, or dspace-jspui-webapp. They could full fork the whole project, and will only ever expose their theme changes
[21:24] <tdonohue> true
[21:25] <scottatm> That is fine, UFR does that and then they can easily (okay, more easily) remerge with someone's master branch when they are ready to update.
[21:25] <PeterDietz> Here at the University of So-Big-We-Wonder-Why-Our-Football-Players-Don't-Receive-Salary, we'll have our hands dirty in every bit of the code. So if you look at ours dspace-api is crazy, submission is crazy, themes are crazy, etc.
[21:25] <tdonohue> though an alternative approach may be to have "out-of-the-box" themes sit in the full fork. But, maybe we actually have a separate "repo" for "additional themes" that anyone can contribute to & also decide to install into their existing DSpace
[21:26] <PeterDietz> so its simpler for me to not split
[21:26] <tdonohue> i.e. two repos: (1) Full DSpace Repo --> has out-of-the-box themes, (2) Theme Repo --> has additional themes which are provided/created by the community
[21:26] <scottatm> Having all the code available for UFR dosn't make their task of just editing the theme.
[21:26] <PeterDietz> StuartLewis and I (in Madrid 2010) were proposing to have a theme development contest
[21:27] <scottatm> There are just some extra code available for them, that they can ignore.
[21:27] <scottatm> When, if, they need to make a more substantial change it will seem natural.
[21:28] * scottatm votes for keeping dspace together as one project.... but I guess I'm biased being from a Why-Don't-Our-Football-Players-Have-A-Salary type of school :)
[21:28] <scottatm> err one core project at least.
[21:30] <tdonohue> The one advantage of the "Theme Repo" idea that I can see is that it won't require the core team to manage/test/maintain every possible cool theme before a new release. Instead, if they were in a separate repo, then they could be updated post-release by community to be compatible again.
[21:30] <mhwood> Another way to split things: pull all of the UIs out of core as separate modules. Themes go along with XMLUI, then.
[21:30] <PeterDietz> Git does support submodules.. Which could be somewhat what we're talking about here. I'm still on the one-big-project side of things. Another thought, kind of like a wordpress themes gallery, would be to have a gallery of xmlui themes, that people build. Some are free (Reference, Kubrick, Mirage), others are $10+ OSU_Snazzy_Theme, $2000 @mire document streaming theme
[21:30] <tdonohue> (but, this is all just a brainstorm)
[21:31] <scottatm> Peter, but if you follow the wordpress example.... you have a core product with at least one theme.... then individual projects for all the other themes.
[21:31] <scottatm> That seems fine to me, so long as there is one basic theme in core project.
[21:32] <mhwood> Yes, we want to keep the property that DSpace just shakes out of the box and runs, I think.
[21:33] <mhwood> (Mutter, mutter, just installed Fedora for the first time and it doesn't *do* anything....)
[21:33] <PeterDietz> .addpoint mhwood
[21:33] <kompewter> mhwood: +1/-0, 1
[21:34] <tdonohue> yea, I wasn't saying we move all themes to an external 'repo'. I agree, DSpace needs to have some base themes out-of-the-box.
[21:34] <mhwood> But if there's a place to go looking for themes, then DSpace only need come with *one*, just so it works without extras.
[21:34] <tdonohue> was just wondering out-loud if it'd be worth having a separate "theme repo" where community developed/maintained (i.e. not-centrally-maintained) themes can be submitted
[21:34] <PeterDietz> I did that the other week too. I never figured out how to upload a file/bitstream into it. I was thinking I had to construct some xml-wrapper first, and gave up.
[21:34] <hpottinger> mhwood: fun thing to hook up to Fedora: https://github.com/emory-libraries/eulfedora
[21:34] <kompewter> [ emory-libraries/eulfedora - GitHub ] - https://github.com/emory-libraries/eulfedora
[21:35] <tdonohue> mhwood: correct. DSpace only needs to come with *one*, as long as it's easy to install others
[21:35] <scottatm> tdonohue: +1
[21:35] <PeterDietz> I think thats a happy enough note to end on today
[21:36] <tdonohue> yep, i probably should get back to work too :) I do like this "themes repo" idea though. We may want to try and make that happen someday soon(ish)
[21:36] <PeterDietz> ./dspace theme-install git://github.com/osulibraries/xmlui-webapp.git
[21:36] <mhwood> Thanks hpottinger: will take a look.
[21:37] <tdonohue> PeterDietz: could be an interesting idea -- install via git repo ;)
[21:37] <hpottinger> PeterDietz: would be a cool tie-in with some of the scriptable theme work you guys are doing.
[21:38] * hpottinger votes for the OSU Snazzy theme becoming *the* theme for out of the box DSpace :-)
[21:40] * PeterDietz votes for DSpace App Store to fund me selling add-ons so I don't have to go to work, so I could actually have time to build clean add-ons in the first place.
[21:40] <tdonohue> +1 hpottinger (and +1 PeterDietz for the nice work on the OSU Snazzy theme)
[21:41] <hpottinger> ooh, DuraSpace App Store ++
[21:42] <tdonohue> yea, I'd love a DuraSpace App store ++ We just need someone to come up with a decent App install/update "framework" that we can work from.
[21:43] <tdonohue> DSpace App Store, I mean
[21:43] <mhwood> Nobody will pay more than $1 for those add-ons -- Apple has folks trained.
[21:44] <hpottinger> $1 a pop adds up
[21:44] <mhwood> Times how many million DSpace sites?
[21:44] <tdonohue> not so sure, these are universities. They willingly throw away money all the time (kidding, mostly)
[21:45] <mhwood> App Store works because of the scale of the market. I think we don't have the volume to make that kind of pricing practical.
[21:45] <tdonohue> only 1,500+ known DSpace sites. So, you'd need them each to buy several add-ons, or charge for updates/upgrades
[21:45] * bbbbb (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[21:46] <hpottinger> well, scale out from what an individual finds an acceptable expense for "let's just try it" software, $1 to a university, I'd say $1K is probably the sweet spot
[21:47] <tdonohue> I still think an App Store would make sense for DSpace though -- it'd just be more like an easy way to install themes/modules from the Admin UI though, ala WordPress (and less about trying to charge for apps -- though maybe eventually it could build to that)
[21:49] <PeterDietz> I'll publish my themes for free. (I reserve the right to put AdWords in.. Ad for Viagra, next to research paper on male anatomy)
[21:49] <tdonohue> again, we're mostly just waiting for someone to figure out a framework for how to easily install/update an "app" (where it may be a module or a theme)
[21:50] * hpottinger mops up the spit-take, thanks a lot, PeterDietz, tea all over my keyboard
[21:50] <mhwood> Theme separation from the rest of DSpace is fairly clean. The module interface...not so much.
[21:51] <tdonohue> mhwood : yea, that's what I was implying by needing a "framework". We essentially need a new "app interface", which makes the separation cleaner. Then, we go back to each module and rework it so it behaves like an "app"
[21:52] <PeterDietz> hpottinger: You're welcome. ;)
[21:53] * mhwood tries not to think about a UML description of all of DSpace.
[21:53] * tdonohue agrees
[21:54] <hpottinger> all these ideas all kind of tie together, though... part of the appeal of Fedora is that it's just a box to put stuff in, with an API to work with... I was struck at OR11 by the number of people sitting around in the halls tinkering with Fedora on their notebooks... having a framework to encourage and reward "just tinkering" would be great
[21:55] <tdonohue> +1 hpottinger
[21:55] * hpottinger wanders downstairs to tell the kids to turn down their computer games
[21:57] <tdonohue> admittedly, there are days where I wish we could find a way to "gut" parts of DSpace and start afresh. Not saying it's all that bad, but it's definitely very inconsistent. Some areas need quite a bit of attention as they really are 10-year old approaches to an ever changing definition of 'repository'.
[21:58] <tdonohue> but, I like the fresh ideas that something like an "app store" could bring to things. It could be a way to potentially slowly migrate all the old, ugly pieces into fresh, new "apps"
[22:00] * bbbbb (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[22:01] <mhwood> Yeah, we need to stare at all of the bits of DSpace that usually make us think, "I'd rather not look at that".
[22:02] <tdonohue> +1
[22:02] <hpottinger> special topic: what needs to go?
[22:02] <hpottinger> or special topic: refactoring
[22:03] <tdonohue> "what needs to go" is hard, as it doesn't necessary need to go away. Just may need a lot of rework/rethinking. So, refactoring may be a better way of putting it
[22:04] <hpottinger> just remembering back to that epic refactoring session that GrahmTriggs put in a while back...
[22:04] <mhwood> Agreed, what needs to go is some of the ways the code is organized rather than any piece we could point to.
[22:05] <tdonohue> again, a part of me does wonder though if we could be more comfortable "refactoring things" if we could figure out an "app store" interface/approach that makes more sense. This direction is parallel to how EPrints has reworked itself ...
[22:05] <mhwood> Maybe the proper approach is to just start at the bottom and ask ourselves, "is this good layering, or could we simplify?"
[22:05] <tdonohue> Eprints essentially created their own App Store and then refactored everything into an "App" that could be easily installed/updated into that store.
[22:06] <tdonohue> mhwood +1 -- yea, simplification may be key here
[22:09] <mhwood> Sorry, must go.
[22:10] <hpottinger> I do think this would be a very beneficial special topic meeting, I think the business logic layer is a great example of this kind of work
[22:10] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:12] <tdonohue> sounds like a good idea for a special topic meeting, and a possible parallel thread on dspace-devel. I'll look into scheduling it
[22:14] <hpottinger> PeterDietz, I'm also lurking in code4lib IRC right now, and saw a mention of ActiveFedora, which you might want to look into if you're still playing with Fedora at all.
[22:15] <tdonohue> ActiveFedora looks really cool (at a glance anyways) -- makes for easier Ruby on Rails development on Fedora. Never tried it myself, just looks pretty cool.
[22:19] <scottatm> tdonohue: You should really take a look at the Play Framework. We've been working with it here for a few smaller projects so far and it has worked out really well.
[22:19] <scottatm> http://www.playframework.org/
[22:19] <kompewter> [ Play framework - Home ] - http://www.playframework.org/
[22:20] <scottatm> It gives you want you want from Ruby/Django but in Java with out all the complexities "groovyness" of Grails.
[22:20] * hpottinger has tinkered with Play Framework a bit
[22:20] <tdonohue> hmmm...cool :) I had heard of it before, just never tried it out.
[22:21] <scottatm> We're working on a batch import tool that might be ready to share sometime in 2013, it will be written in play.
[22:21] <tdonohue> perhaps a novice/obvious question: any thoughts on whether Play could help with DSpace development?
[22:21] <scottatm> yes.... tremendously... but it's a big project.
[22:21] <hpottinger> tdonohue that would be totally cool
[22:21] <tdonohue> aha. ok, will have to take a look
[22:21] <scottatm> I think it's an ideal framework for a DSpace UI.
[22:22] <scottatm> It's something that you can hand over to a CSS/HTML developer and let them tweak, robustly supports tests and real time reloading.
[22:22] <tdonohue> yea, I personally feel like DSpace needs to be taking more advantage of modern frameworks (that can allow for more rapid development/prototyping). Play may be a good match in that way
[22:22] <hpottinger> would get us into writing Scala, too
[22:23] <scottatm> One of the really great things for java developers is the dynamic reloading. So you change a java file, and then click on your browser to re-load the page. It's compiled in realtime. No need to run a mvn package, or anything.
[22:23] <scottatm> Scala is completely optional.
[22:23] <tdonohue> hmm... quite cool.
[22:23] <scottatm> (although the templating language for the 2.0 release will be scala based)
[22:24] <scottatm> That's very minimul, it's not like you need to be a scalar developer or even know what scala is.
[22:24] <tdonohue> scottatm -- do you happen to have any Play projects that you are willing to share as a "sample project". Or are you all still just getting familiar with all that Play can do?
[22:26] <scottatm> sure.
[22:26] <scottatm> I got three for you:
[22:27] <scottatm> https://github.com/TAMULib/Shibboleth-play - A play "module" that supports Shibboleth authentication
[22:27] <kompewter> [ TAMULib/Shibboleth-play - GitHub ] - https://github.com/TAMULib/Shibboleth-play
[22:27] <scottatm> https://github.com/TAMULib/PiperApp - The afore mentioned batch import tool this is a long ways from ready - it has no UI right now.
[22:27] <kompewter> [ TAMULib/PiperApp - GitHub ] - https://github.com/TAMULib/PiperApp
[22:28] <scottatm> https://github.com/TAMULib/DirectoryApp - This is our first complete application. This is probably the best one to look at, it is an employee directory for our library. Browse LDAP, view homepages, etc....
[22:28] <kompewter> [ TAMULib/DirectoryApp - GitHub ] - https://github.com/TAMULib/DirectoryApp
[22:29] <scottatm> Grab the DirectoryApp, install play, then run "play test"
[22:29] <scottatm> It will bring up the directoryApp in a test mode, from where visit the url: http://localhost:9000/directory/ and see the application with test data.
[22:30] <scottatm> Or visit the URL: http://localhost:9000/@tests, click run all tests and prove that the application works.
[22:30] <tdonohue> cool. thanks! I just figured that might make it easier to dig around and see how it all works
[22:30] <tdonohue> (didn't realize TAMULib was on github. good to see!)
[22:31] <scottatm> Just some projects that we don't mind publishing open source.
[22:31] <scottatm> Others we're a bit skiddish about... we're still using SVN internally for those.
[22:32] <hpottinger> scottatm, I'm going to check out your PiperApp, and may be in touch about it
[22:33] <scottatm> hpottinger: it is at the very early stages.... there's not much there right now but hope.
[22:33] * hpottinger is OK with just hope
[22:33] <tdonohue> :)
[22:35] <tdonohue> this gives me lots to look at. :) Play Framework may also be a good topic to bring up in any aforementioned "Refactoring/Rethinking DSpace" Special Topic meeting we have.
[22:36] <scottatm> It works well with spring too. The directoryApp only uses spring a little bit, but the PiperApp is very much Spring-ified.
[22:40] * hpottinger has to run, later folks!
[22:40] * hpottinger (~hpottinge@mu-108022.vpn.missouri.edu) has left #duraspace
[23:04] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:46] * ablemann (~alexleman@lemanal.new.xen.prgmr.com) Quit (*.net *.split)
[23:46] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) Quit (*.net *.split)
[23:46] * PeterDietz (~peterdiet@128.146.173.59) Quit (*.net *.split)
[23:46] * scottatm (~scottatm@voyager108.evans.tamu.edu) Quit (*.net *.split)
[23:56] * Disconnected.
[23:56] -niven.freenode.net- *** Looking up your hostname...
[23:56] -niven.freenode.net- *** Checking Ident
[23:56] -niven.freenode.net- *** Found your hostname
[23:56] -niven.freenode.net- *** No Ident response
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.