Timestamps are in GMT/BST.
[0:10] * benoitg (~benoitg@132.211.90.125) has joined #duraspace
[1:26] * benoitg (~benoitg@132.211.90.125) Quit (Ping timeout: 260 seconds)
[1:33] * benoitg (~benoitg@132.211.90.125) has joined #duraspace
[2:52] * benoitg (~benoitg@132.211.90.125) Quit (Ping timeout: 248 seconds)
[6:55] -wolfe.freenode.net- *** Looking up your hostname...
[6:55] -wolfe.freenode.net- *** Checking Ident
[6:55] -wolfe.freenode.net- *** Found your hostname
[6:55] -wolfe.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
[10:49] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[11:47] * root (~root@gwdi.di.uminho.pt) has joined #duraspace
[11:47] * root is now known as Guest69132
[11:47] * Guest69132 is now known as elschlomo
[11:48] * elschlomo (~root@gwdi.di.uminho.pt) Quit (Client Quit)
[12:58] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:01] * tdonohue (~tdonohue@c-24-13-90-87.hsd1.il.comcast.net) has joined #duraspace
[15:25] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) Quit (Ping timeout: 240 seconds)
[15:25] * grahamtriggs (~Graham@vpn-client-37.city.ac.uk) has joined #duraspace
[16:21] * benoitg (~benoitg@184.151.115.127) has joined #duraspace
[16:21] * grahamtriggs1 (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[16:24] * grahamtriggs (~Graham@vpn-client-37.city.ac.uk) Quit (Ping timeout: 240 seconds)
[16:50] * benoitg (~benoitg@184.151.115.127) Quit (Ping timeout: 252 seconds)
[17:00] * grahamtriggs1 (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[17:09] * benoitg (~benoitg@184.151.115.127) has joined #duraspace
[18:41] * benoitg (~benoitg@184.151.115.127) Quit (Ping timeout: 248 seconds)
[18:58] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) has joined #duraspace
[19:52] * hpottinger_ (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:56] <tdonohue> Hi all, reminder that our weekly DSpace Devel Mtg starts in ~5 mins. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-01
[19:56] <kompewter> [ DevMtg 2012-02-01 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-01
[19:58] * richardrodgers (~richardro@18.111.95.44) has joined #duraspace
[19:59] * AmyLana (80cea2c2@gateway/web/freenode/ip.128.206.162.194) has joined #duraspace
[20:00] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome! It's time to start up our weekly DSpace Developers Mtg. General Agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-01
[20:00] <kompewter> [ DevMtg 2012-02-01 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-01
[20:01] <tdonohue> as usual, we'll kick things off with our JIRA catchup review for first ~15mins
[20:01] <tdonohue> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-937+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-937 ] - [#DS-937] Stop using Email Address as Identifier for DSpace User. - 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-937+ORDER+BY+key+ASC
[20:01] <tdonohue> today we start up with DS-937
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-937 ] - [#DS-937] Stop using Email Address as Identifier for DSpace User. - DuraSpace JIRA
[20:02] * JoseBlanco (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) has joined #duraspace
[20:02] <tdonohue> obviously this is a new feature / idea. But, do we have any immediate thoughts around this idea that we want to voice now?
[20:03] <mhwood> It's a good time to be thinking about it, with 3.0 being pulled together.
[20:03] <tdonohue> +1 mhwood
[20:04] <robint> Sounds good, although its not something that has been a problem personally
[20:04] * benoitg (~benoitg@173.246.5.249) has joined #duraspace
[20:05] <richardrodgers> I guess I'd like to see a bit more of a fleshed out proposal...
[20:05] <tdonohue> I think the only area where I've seen this as a potential "problem" is that we currently don't allow folks to change their associate email (cause it's tied into so much other stuff, as it's the main user ID)
[20:05] <mhwood> Exactly: it pins down something that should be a mutable attribute of the profile.
[20:06] <tdonohue> i.e it'd be nice to allow users to easily change their email addresses, and use something else as the permanent "user ID"
[20:06] <robint> The last para of the last comment by Mark seems to be on a slightly different topic, or have I misunderstood ?
[20:07] <mhwood> If I move to a different institution, or switch ISPs, then I get a new address. So I either have to re-register and abandon the old registration, or give up on subscribing to change notices, etc.
[20:07] <tdonohue> ok, sounds like there's some general "interest" here, just need a direction/proposal/prototype mapped out a bit better
[20:08] <tdonohue> robint: yea, mdiggory has a few topics interwoven here in his discussion of "provenance"
[20:08] <tdonohue> robint: I think the main point is that 'email' is currently tied into so many things -- we need to "untie" it a bit, and think about using something else as the ID, so that folks can change their email
[20:08] <mhwood> I think the provenance stuff comes in because we record NetID there instead of EPerson_ID?
[20:08] <hpottinger_> One thing to at least keep in mind, if we switch to truly unique identifier, there will be some pressure to utilize our repository to produce metrics
[20:09] <tdonohue> provenance currently uses email actually, I believe
[20:09] <mhwood> Define "unique".
[20:09] <hpottinger_> emplid
[20:09] <mhwood> Unique within a DSpace instance?
[20:10] <mhwood> Hmmm, the user might not *be* an emp, anywhere.
[20:10] <hpottinger_> unique within DSpace is fine, an ID used institutionally or more widely might lead to situations where certain researchers get "spooked"
[20:10] <tdonohue> yea, I was just thinking this new "ID" needs to just be unique within a DSpace instance (and it may even be generated/created internal to DSpace). It may be "mappable" to an employee ID or similar, but we don't have to use an External/Institutional ID as this "ID"
[20:11] <tdonohue> it may just be that all we're moving towards is having a dspace "username". You may even be able to choose your own username, it just needs to be unique in your DSpace.
[20:11] <mhwood> The storage layer already creates a unique-within-instance EPerson ID. We should use that, for example to look up external identifying information related to a provenance record.
[20:11] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[20:12] <mhwood> Suppose your "username" is your EPerson ID, but you identify yourself as an EPerson by presenting your current email, NetId, retina scan, whatever.
[20:12] <richardrodgers> db keys are a bit fragile as IDs...
[20:13] <tdonohue> yea, I'd rather avoid having db keys as the "ID". It makes things like "Backup & Restore" much harder (as you then have to try and retain DB IDs)
[20:14] <tdonohue> So, I prefer something like a "username" which is required to be unique
[20:14] <mhwood> OK, whatever, but it doesn't have to be either visible or enterable by the user whom the EPerson represents.
[20:14] <tdonohue> in any case, it seems like we have a lot of useful ideas here. I'll take an action to post a copy of this discussion into comments of Ds-937
[20:15] * hpottinger_ remembers Kim Shepherd's slide at OR11 urging us to treat people as objects
[20:15] <tdonohue> mhwood : point taken
[20:16] <PeterDietz> speaking of kshepherd...
[20:16] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:17] <tdonohue> Ok, sounds like this may be a larger topic in general. I'll post these comments over to Ds-937 and we can start brainstorming some more both there & in future meetings
[20:17] <mdiggory> My ears were burning...
[20:17] <tdonohue> mdiggory -- yea, read back in the logs. We just spent a good while on Ds-937
[20:18] <mdiggory> ah yes... that one
[20:18] <tdonohue> Ok, we're gonna just stop the JIRA review there for today, as we have a rather 'full' agenda today, and we already spent a good 15+mins on that one :)
[20:19] <grahamtriggs> I have a very simple take for all identifiers - either find a bloody good reason not to, or something that is better for the circumstances, otherwise just use UUIDs *everywhere*
[20:20] <tdonohue> So, the next topic up is to discuss DS-1021, which is of high interest to DCAT. AmyLana (of DCAT & U of Missouri) is joining us today. I know where hoping to see if we can find a few volunteers or interested persons
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-1021 ] - [#DS-1021] Add integration with an online document viewer (like flash based FlexPaper) - DuraSpace JIRA
[20:20] <tdonohue> AmyLana, anything you wanted to say in support of DS-1021, etc?
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-1021 ] - [#DS-1021] Add integration with an online document viewer (like flash based FlexPaper) - DuraSpace JIRA
[20:20] <AmyLana> Hi everyone--thanks for fitting me in today. I'm actually here begging for 2 volunteers, the first for https://jira.duraspace.org/browse/DS-1021
[20:20] <kompewter> [ https://jira.duraspace.org/browse/DS-1021 ] - [#DS-1021] Add integration with an online document viewer (like flash based FlexPaper) - DuraSpace JIRA
[20:20] <kompewter> [ [#DS-1021] Add integration with an online document viewer (like flash based FlexPaper) - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1021
[20:21] <AmyLana> I understand that Ohio State/Peter Dietz may have some code that could act as a starting point.
[20:23] <PeterDietz> The part I've built, looks like: https://picasaweb.google.com/115522466408243604820/OSULibrariesDSpaceDesigns#5516829984952797698
[20:23] <kompewter> [ Picasa Web Albums - Peter Dietz - OSU Libraries... ] - https://picasaweb.google.com/115522466408243604820/OSULibrariesDSpaceDesigns#5516829984952797698
[20:24] <tdonohue> PeterDietz, this is the 'unfinished' XMLUI 'book-reader' theme you mentioned last week, right? With code up at: https://github.com/osulibraries/xmlui-webapp/tree/master/themes/book-reader
[20:24] <kompewter> [ themes/book-reader at master from osulibraries/xmlui-webapp - GitHub ] - https://github.com/osulibraries/xmlui-webapp/tree/master/themes/book-reader
[20:24] <PeterDietz> Yep, that code still works, I wouldn't say its unstable buggy. But we decided not to use it due to some limitations.
[20:24] <AmyLana> When DCAT discussed this issue, we'd hoped to roll a document viewer into a streaming server service which could also handle a/v needs. Tim advised me that these are really two different issues, so I created a second JIRA issue for the streaming (https://jira.duraspace.org/browse/DS-1115)
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-1115 ] - [#DS-1115] Integrating a streaming server with DSpace to present audio and video files is desirable - DuraSpace JIRA
[20:25] <PeterDietz> Using it depends on your definition of "document".. In our case, the pages of the book are JPEG's, numbered sequentially, then we just plug in those jpeg's to be "Pages" of the book
[20:25] <PeterDietz> If your Document is a PDF, then I don't think you can use this as-is, because it expects an image.
[20:26] <tdonohue> oh, I see, so the 'book-reader' requires that you have Images already created.
[20:27] <AmyLana> Sounds like it'd be good for a digital library application. Our IR holds mostly pdfs, though; at a guess PeterDietz, would what you have be adaptable for pdfs?
[20:27] <hpottinger_> The Snazzy theme would provide a framework for embedding all kinds of players, not just a page turner; what we'd need for a page turner is probably a streaming image server, to generate tiles on the fly from something like JPEG2000 or pyramidal TIFFs
[20:27] <mdiggory> Yes Page Turners, unless there is a components of some document streaming service, are going to need to process the content into page fragments.
[20:27] <richardrodgers> Is there a use-case for server-side PDF rendering - really big files maybe?
[20:27] <mhwood> Let me put on my end-user hat for a moment. It really frosts me when some page ignores my choice of helper app.s and forces a particular viewer down my throat. That's not the way the WWW works; I already told my browser how to display video and I expect my preference to be obeyed.
[20:28] <PeterDietz> you could build a media-filter, that converts ORIGINAL research.pdf to another bundle like IMAGES-research-pdf (image1, image2, image3, ...)
[20:28] <mhwood> PDFs should be linearized so that viewers can ask for the pages out-of-order.
[20:28] <hpottinger_> digitization produces really big PDFs
[20:28] <tdonohue> mhwood: I don't think anyone would force you to use the page-turner. You could still download the PDF (unless it was access restricted). But, the page-turner provides a potential "preview" of the document (no need to download)
[20:29] <hpottinger_> linearization doesn't support random seek
[20:30] <mhwood> *some*thing does. I've seen it working. I'm sure I have. With Adobe Reader.
[20:31] <hpottinger_> well, it kinda-sorta does, if you happen to have downloaded the part of the file you need, you can turn to that page, but to fully support random seek, you have to download the entire file
[20:31] <mdiggory> richardrodgers: yea, in the case of PDF's a server side component would extract and deliver individual pages, but I suspect that it would need to be pretty intimate with the filesystem, like DJatoka and JPEG2000
[20:32] <hpottinger_> you also need a server that's capable of byteserving a PDF
[20:32] <mhwood> http://blog.nitropdf.com/2011/01/technology-file-structure/
[20:32] <kompewter> [ Inside the technology: PDF File Structure ] - http://blog.nitropdf.com/2011/01/technology-file-structure/
[20:32] <PeterDietz> I like the approach used by Brasiliana's Corisco: https://github.com/brasiliana/Corisco/blob/master/docs/CoriscoDiagram.png
[20:32] <kompewter> [ docs/CoriscoDiagram.png at master from brasiliana/Corisco - GitHub ] - https://github.com/brasiliana/Corisco/blob/master/docs/CoriscoDiagram.png
[20:33] <mhwood> I recall seeing code in XMLUI to support byte-ranges.
[20:33] <tdonohue> may be a daft/dumb question (I don't know this area well): Are there any decent PDF page-turners that run entirely client side (Javascript, Flash or similar)? Or do they all need something installed alongside DSpace on the server itself?
[20:33] <richardrodgers> mdiggory: OK, but those systems are really for higher-res content than article PDFs, that''s why I'm trying to understand the scope of the needs
[20:33] <PeterDietz> If you use the Chrome web browser, it has embedded pdf support. So if you use HTML embed, it works perfectly.
[20:34] <tdonohue> PeterDietz: good to know, but I doubt we can force everyone to use Chrome ;)
[20:34] <hpottinger_> tdonohue: Multivio is client based, but it has a server side piece that blows up and converts PDFs to images
[20:35] <robint> I'm trying to get the Multivio gang to present at OR12. I'm hoping it might generate more general discussion.
[20:36] <PeterDietz> Another option is the Google Docs viewer...
[20:36] <hpottinger_> PeterDietz: I like Corisco, too, the Djatoka server it uses could be used for various page turners
[20:37] <PeterDietz> DSpace, using Google Docs Viewer https://wiki.duraspace.org/display/DSPACE/Document+Preview+with+Google+Docs+viewer
[20:37] <kompewter> [ Document Preview with Google Docs viewer - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Document+Preview+with+Google+Docs+viewer
[20:37] <mdiggory> I think the needs are (1) novel user experience (2) reduced bandwidth for reviewing large PDFs prior to downloading and TBH, the most important I can think of (3) limiting access to the original
[20:37] <tdonohue> Multivio sounds interesting. Guess I was just curious if everything is going to require generating separate files on the server (i.e. potentially increasing storage needs, esp. for sites with lots of PDFs)
[20:38] <hpottinger_> tdonohue: that's my concern, too, I don't think you can get away from generating tiles for a tiling image viewer, though... I just don't want to have to store them permanently, for everything in the repository
[20:39] <tdonohue> AmyLana, do you (or anyone else in DCAT) have a good sense of the user needs here (i.e. do they match up with what mdiggory has listed above?)
[20:40] <tdonohue> just curious if most people want this feature in order to 'limit access' to the original. Or if it's more about a novel user experience / quick view in the browser?
[20:40] <AmyLana> Yes, I think mdiggory is on exactly the right track, though I'm not sure that limiting access to the original is necessarily a concern. Mainly it's for user friendliness.
[20:40] <mdiggory> hpottinger_: TBH this why we end up with formats like JPEG2000 and DJatoka, these are analogs to the Document viewer problem, but speak about the need to not have to generate large numbers of derivatives
[20:42] <mdiggory> AmyLana: limiting access to the original is policy driven by the institution, or at least we have seen there be a need for it, either due to third party licensing concerns or an interest in cost recovery
[20:42] <tdonohue> mdiggory: so, are you saying this could also be done potentially via a MediaFilter that converts PDF (or similar) -> JPEG2000, and then provide a JPEG2000 viewer of that set of files (which is likely in a new Bundle)?
[20:42] <mdiggory> no that wasn't my suggestion.
[20:43] <AmyLana> mdiggory: we have some originals to which we'd probably limit access as well, I just don't know that it was a driving concern in the DCAT discussion.
[20:44] <hpottinger_> tdonohue: I would not want to implement anything that required storing of derivatives, just doesn't seem like an efficient use of resources
[20:44] <mdiggory> tdonohue: my suggestion is that in JPEG2000 there is a requirement for DJAtoka to have random file access to the actual file on the file system. Integrations between DJatoka and DSpace require adding access to the local file reference, otherwise the result is that you need to duplicate the contents of the Bitstream to a temp file just to access it. In fact, this is also the issue with DuraCloud support for DJatoka.
[20:45] <tdonohue> ok, makes more sense
[20:45] <mdiggory> My point is just that without breaking the document up into individual bitstreams per page, that support for native document streaming will requires some sort of service similar to DJatoka.
[20:45] <PeterDietz> hpottinger_: its a trade-off. Pay up-front, in cost of storage, or pay on-demand in CPU (and user's time) every time a client requests a new file
[20:46] <hpottinger_> "access to the local file reference" is exactly what is needed for integrating any sort of streaming server
[20:46] <hpottinger_> PeterDietz: but the agreement is to store this stuff *forever* :-)
[20:47] <tdonohue> +1 PeterDietz -- this was what I was trying to get to. Are we leaning towards an "on-the-fly" generation of any derivatives, or are we going to have to figure out a way to know which derivatives to keep?
[20:48] <mdiggory> If you put it in a bitstream, keep it, if you dump it somewhere in the filesystem and access it separately... then I suspect its not under and archival policy
[20:49] <hpottinger_> On the fly generation of derivatives is acceptable, keep a cache of most-requested files to limit impact to usability. It's how DLXS (Michigan's digital library software).
[20:50] <PeterDietz> Other systems call this "Disseminators"
[20:50] <mdiggory> AmyLana: Yes access control and page turning are somewhat orthogonal
[20:50] <tdonohue> hpottinger_: that sounds like a reasonable approach.
[20:51] <mhwood> We'd need some suitable mechanism for evicting stale cache entries.
[20:51] <tdonohue> so, it sounds like we are narrowing down slightly on possible approaches. Anyone here interested in "digging deeper" into potential 'implementations' (or even just brainstorms) and reporting back on problems/decision points we may need to still make?
[20:51] <mdiggory> PeterDietz: true, but disseminators are services, not necessarily speaking towards what is stored behind them and its preservation policy...
[20:53] <hpottinger_> todonohue: I'm already "digging deeper", in that I've committed to having some kind of DL interface for our IR by the end of the year. So, I volunteer to report back.
[20:53] * tdonohue (crickets) everyone seems interested, but no one has time to dig in deeper?
[20:54] <mdiggory> I think that we would participate in any dialogs to assure if theres beneficial alignment with our existing solution
[20:54] <tdonohue> hpottinger_ : sounds good. It sounds like you were. Just wasn't sure how high priority this really was for you
[20:55] <hpottinger_> tdonohue: my top priority, actually
[20:55] * tdonohue wonders out-loud if this would be a good project to get over to GitHub -- anyone can then fork & help hpottinger out / provide feedback / etc
[20:55] <richardrodgers> tdonohue: FWIW, we are looking at some solutions (based, I thing on Internet archive tools) for TIFF page turners, I just don't know if it addresses the needs here..
[20:55] <richardrodgers> thing->think
[20:56] <mhwood> So, can I have an account setting: (I already have my own viewer for [ ]PDF, [ ]video, [ ]audio -- don't try to be helpful)?
[20:56] <mdiggory> I think where this is of interest to myself and other @mire team members is to see some work in DSpace on supports a more concrete "Disseminators" capability
[20:56] <tdonohue> richardrodgers : there may be overlap. hard to say. Again, I wonder if we all got our projects out in a more 'public' area (GitHub or similar) if that would help us find those potential overlaps
[20:58] <hpottinger_> I like the idea of using github for this collaboration, especially if parts of Corisco (already on GitHub) might be beneficial
[20:58] <tdonohue> mhwood: actually I think it's more like how a "thumbnail" works. The viewer would be embedded into the Item page (if enabled in DSpace), but there'd also be a link nearby to just download it and view it however you want.
[20:58] <mdiggory> there are many solutions for various "disseminations" already out there, where I'd like to see the community go is in assuring that DSpace provides a means for various approaches to "play nice" with eachother.
[20:58] * tdonohue has taken the role of "Github-promoter" from PeterDietz
[20:59] <PeterDietz> ;)
[20:59] <hpottinger_> mdiggory: I'm willing to be led, if you have an idea of how I should go about approaching the problem
[21:00] <tdonohue> +1 to the idea, mdiggory. Just not sure if we can jump straight to a "use whatever approach you want" solution that is flexible enough. (Though if we can, great. Just think a "quick solution" may also be helpful, though we need to keep in mind a larger future solution)
[21:00] <mdiggory> and likewise to support in the UI for playing nice with various viewing platforms (ipad, android, etc, etc, etc)
[21:00] <tdonohue> +1 mdiggory to that
[21:01] <tdonohue> ok. wow. it's already the top of the hour. Where does the time go :)
[21:01] <AmyLana> Thanks for taking the time on this--it's much appreciated!
[21:01] <hpottinger_> +1 mdiggory, would have to avoid flash for viewers
[21:02] <tdonohue> So, since we are over time, you are welcome to leave whenever. Just a few small things to mention:
[21:02] <tdonohue> (1) I really wanted to promote the "Modernizing DSpace Kernel" work that richardrodgers has started on GitHub. It's really early days, but it's a great idea: https://github.com/richardrodgers/mds
[21:02] <kompewter> [ richardrodgers/mds - GitHub ] - https://github.com/richardrodgers/mds
[21:03] <mdiggory> the above topic makes me think about METS:interfaceMD ...
[21:03] <tdonohue> (If anyone out there is interested in chipping in with the "modernizing" work, I'd encourage forking & helping out. I plan to do so myself)
[21:04] <mdiggory> I only heard about this yesterday... a bit behind I guess...
[21:04] * hpottinger_ really wants to dig into AuthenticationManager
[21:04] <richardrodgers> yep, plenty of room in the pool, jump right in!
[21:04] <tdonohue> (2) As I mentioned in dspace-commit list, I'm leaning towards having some sort of "DSpace Developers Virtual Summit" via something like Google+. I was wanting some feedback on that idea today, but I may just bring this to dspace-commit again (unless anyone has immediate thoughts)
[21:05] <tdonohue> (more info on that Virtual Summit idea in the agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-01)
[21:05] <hpottinger_> +1 count me in
[21:06] <tdonohue> That was all the topics I really wanted to mention today. But, I will hang around here if anyone has feedback on the "Summit" idea, or wants to talk anything else
[21:07] <mdiggory> would like to see some focus on usage of spring and some of the services
[21:07] * tdonohue says feel free to head out if you need to. The "official" meeting is closed -- now starts any "unofficial" post-meeting discussions
[21:07] <mdiggory> in both the summit and mds
[21:07] * AmyLana (80cea2c2@gateway/web/freenode/ip.128.206.162.194) has left #duraspace
[21:09] <PeterDietz> richardrodgers: I have a question about MDS... So much has been pruned, and re-arranged... Why start from a bare repository, vs, morphing the DSpace/DSpace repository?
[21:09] <mdiggory> For instance, theres interest internally in rewriting the MediaFilters and other plugins to be more easily used in spring configuration.
[21:10] <tdonohue> mdiggory: I think that's a good idea. But, TBH, I also feel we need to leave things open for "other options". I see the "summit" as a way to start to look more closely at larger issues/refactoring that we may want. If services/spring fits in well, then great! But, I personally don't make that a requirement for everything.
[21:10] <mhwood> TBH when I think about Services I often find myself wondering why I shouldn't just use Spring to inject the stuff I need, since it's there anyway.
[21:10] <mdiggory> mhwood: thats why its there...
[21:11] <richardrodgers> PeterDietz: mainly, agility. Refactors would take much longer on 10X-20X size of code (whole DSpace). Second, I did not want experiments to be bound by the status quo..
[21:12] <richardrodgers> mdiggory: see the other repo - ctask, It contains a whole rewrite of MediaFilter as curation suite..
[21:12] <mdiggory> So in that case they are bound to being curation tasks.
[21:12] <mdiggory> I'm talking about just standalone beans separate from configuration
[21:13] <mdiggory> configure them in the container of your choice...
[21:13] <PeterDietz> I have a howto question also.. What is required to "bootstrap" mds? i.e. just... mvn package...?
[21:13] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Ping timeout: 245 seconds)
[21:13] <richardrodgers> PeterDietz: what do you mean by 'bootstrap'?
[21:13] <PeterDietz> ...because mvn package failed a bunch of tests.. or, is this where I should jump in a fix it..
[21:14] <PeterDietz> by bootstrap i mean, how do I compile it so that "it works"
[21:14] <mhwood> Aren't tests known to be broken right now?
[21:14] <PeterDietz> so that I could then invoke the dspace launcher
[21:15] <richardrodgers> PeterDietz: it should compile, As I said in the intro - I broke the unit-testing (I think its related to a change in connection pooling) -that's why it doesn't install
[21:15] * JoseBlanco (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) has left #duraspace
[21:16] <tdonohue> you can still install by turning off the tests for now. But, we do need someone to help fix the tests (and build more tests for new stuff)
[21:18] <mhwood> I was working on "modularizing" the dspace-api testing framework a while back. Then right before 1.8 lots of patches landed, lots of stuff got moved, and I couldn't keep up. I need to get that going again.
[21:18] <tdonohue> a huge +1000 mhwood. That work was looking really really promising (from what i gathered on lists, etc)
[21:19] <PeterDietz> a haa.. I can build mds successfully with: mvn package -DskipTests
[21:20] <richardrodgers> prize to whomever figures out how I screwed up the tests....
[21:20] * PeterDietz its on
[21:20] <hpottinger_> prize?
[21:20] <tdonohue> beer?
[21:20] <tdonohue> :)
[21:20] <richardrodgers> beers !
[21:21] <mhwood> Ooh, do I see that pluggable assetstores have surfaced? Incentive!
[21:22] <richardrodgers> mhwood: yes, that's in there - I wanted to remove the SRB stuff (very obsolete!)
[21:23] <tdonohue> is there a "running list" of things that have surfaced/changes (even at a higher level) in MDS? Or is that all just in that README file on the homepage?
[21:24] <PeterDietz> My point for "why new repository", was because there was no revision history
[21:24] <richardrodgers> tdonohue: for major stuff, yes it's in the README - I'll try to maintain that
[21:25] <PeterDietz> so tim's point about what's changed.. can't be deduced without manually directory diff'ing from "DSpace"
[21:25] <tdonohue> +1 to maintaining that. Anyone else adding changes in should also update the README
[21:25] <tdonohue> PeterDietz: yea, I see the point. At the same time, I also see richardrodgers point about a "fresh start" (not being bound by status quo).
[21:25] <tdonohue> so, I'm torn :)
[21:26] <richardrodgers> PeterDietz: true, although henceforth, the git commits will tell the tale...
[21:27] <richardrodgers> For instance, I'm now working on a (very small-scale) example of moving 'config' data into DB..
[21:29] <richardrodgers> I'm starting with very simple stuff - i.e. the launcher.xml data. It really is a command 'registry' rather than config data, so I plan to load it at install like bitstream registry. Then, when new modules are added that have a CLI interface, we can simply update the DB registry.
[21:31] <mdiggory> richardrodgers: my Services tutorial at OR used launcher as an example of using spring configuration and making it easy to write new commands without needing to put configuration files
[21:31] <mdiggory> the point was that it didn't need to even be in a config file, nor a db
[21:32] <mdiggory> just annotated in the code and have an interface
[21:33] <richardrodgers> mdiggory: sure, that's also a way to go - the point is to break the mold of putting everything in dspace.cfg
[21:33] <mdiggory> likewise... https://wiki.duraspace.org/display/DSPACE/The+TAO+of+DSpace+Services
[21:33] <kompewter> [ The TAO of DSpace Services - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/The+TAO+of+DSpace+Services
[21:34] <mdiggory> Anyhow, this was a working example whien I left it.
[21:34] <mhwood> Indeed, we've shoehorned a lot of stuff into Properties format that didn't want to go.
[21:35] <mdiggory> Our focus lately in Discovery (1.8.0 on) is in getting things out of dspace.cfg that we want to give richer configuration capabilities upon
[21:37] <mdiggory> I do still see a want need for seeing certain config in the database. Especially if we want to add granular configuration to the community/collection hierarchy
[21:37] <mdiggory> so don't think I'm opposing that work...
[21:38] <tdonohue> at the same point in time, we should work towards providing ways to update many (most?) configurations via a Admin UI -- i.e. make it easier to configure DSpace for non-techies
[21:38] <tdonohue> (which I think is what the DB config route opens up)
[21:38] <mdiggory> I"m just dichotomizing configuration on "application" and "runtime"
[21:38] <richardrodgers> mdiggory: I agree, that's why I like doing these experiments - decide what makes sense in flat properties files, what DB, what XML config, what Spring annotation, etc
[21:39] <mhwood> One way to decide: is this a knob for the person who installs DSpace (configur in Spring) or the person who administers the repository (configure in DB with admin. UI).
[21:39] <mhwood> The person who assembles DSpace also probably wants to use Spring.
[21:40] <mdiggory> Ok, so launcher commands are generally code. so I think of their definition as being in code (spring), whereas, some of the features of those commands may be configurable in the system (db/props)
[21:41] <grahamtriggs> Actually, it's more like: is it a knob for someone [re]compiling DSpace (Spring annotation), Is it a knob for someone installing / maintaining DSpace (Spring configuration file), or a knob for an admin / user (config in DB)
[21:41] <mdiggory> And this is the same take as the original DSpace 2.0 services took and most of those features were still retained in the 1.8.x version
[21:42] <mdiggory> yes, yes and yes
[21:42] <tdonohue> yep, definitely different levels of config. i agree
[21:44] <mdiggory> 1.) if there is a command defined in java code, the existence of that command and its ability to be called shouldn't require having to fill out a database table or altering a spring configuration file.
[21:44] <KevinVdV> Need to run cya guys
[21:44] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) Quit ()
[21:45] <mdiggory> those levels of configuration for managers and admin should be only tuning the command.
[21:46] <mhwood> Ugh, exception: there's one Launcher command that is not backed by Java code: the one that means, "just calculate the classpath and write it to stdout".
[21:46] <mdiggory> hows it implemented?
[21:46] <richardrodgers> I guess I was coming at this in terms of add-on modularity - so the maintenance knob and the admin knob look a lot alike sometimes...
[21:47] <mhwood> Good point -- I think it's an exception in the script itself. Checking....
[21:49] <richardrodgers> Unfortunately, I have to run...bye all
[21:49] <mhwood> Eek, where did it go?
[21:49] * richardrodgers (~richardro@18.111.95.44) Quit (Quit: richardrodgers)
[21:50] <PeterDietz> catching up... I had an idea that it would be nice for collection-admin's to be able to go to EditCollection, and click a bubble to choose which theme should apply to said collection.
[21:50] <mdiggory> richardrodgers: well I assume there are grey areas between each knob... for instance, if you write a command that allows you to execute some script in a BSF or the like, then that may require a little bit more fucntionality at the application level.
[21:51] <mdiggory> But thats more like a BSF Command Launcher, not a BSF Command.
[21:51] <mhwood> How we convey that to Cocoon will be interesting.
[21:52] <mdiggory> ie is ./dspace my-bsf-command or is it ./dspace bsf my-bsf-command
[21:53] <mdiggory> or is it ./dspace script ./path/to/my/bsf.script
[21:54] <mdiggory> or is it ./dspace script db-key-of-script
[21:55] <mdiggory> \me fails to notice richardrodgers has left the room
[21:55] <hpottinger_> PeterDietz, I like that idea, would be really handy to also allow community/collection admins to load their theme files, though that may be a bit wild and crazy
[21:58] <mdiggory> both are good ideas
[21:59] <tdonohue> +1 to those ideas. I think in general, we need to put *more control* in the Admin UI, and give that control to DSpace Admins & Comm/Coll Admins
[22:00] <mdiggory> we've suggested them both on past project as solutions, but usually fell outside of scope for the client. Sounds like a good community project.
[22:01] * hpottinger_ dimly remembers there's a ticket for refactoring the adminUI... or maybe it was just suggested here?
[22:02] <tdonohue> So, I'm in favor of *2* levels of configs (though this might just be similar to grahamtriggs 3 levels, I just lump the first two together): (1) Configs needed to install something (likely go in Spring or similar), and (2) Configs needed to actually "configure/modify/setup" that thing once installed (should mostly move to the DB & UI)
[22:02] <tdonohue> refactoring the Admin UI gets talked about a lot :) Not sure if we have a ticket or not. It's rather a 'broad' topic though, so we may want to have specific tickets based on exactly which part of Admin UI we are refactoring
[22:03] <mhwood> Probably wants some more structure to the admin. UI. Simple settings just need grouping, while a few things will want their own custom pages. Right now isn't it custom pages for all?
[22:03] <mdiggory> tdonohue: +1
[22:04] <hpottinger_> mhwood, my recollection is that it's "custom pages for all"
[22:09] <mhwood> Must go....
[22:10] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:24] * grahamtriggs (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving.)
[22:40] <hpottinger_> mdiggory: would you be available for chatting about ideas re: DS-1115 (not now, later in week)?
[22:40] <kompewter> [ https://jira.duraspace.org/browse/DS-1115 ] - [#DS-1115] Integrating a streaming server with DSpace to present audio and video files is desirable - DuraSpace JIRA
[22:41] <mdiggory> is there anything in the works?
[22:43] <hpottinger_> kshepherd has something for streaming audio/video, Corisco and Ohiolink have done work with integrating an image server
[22:44] <hpottinger_> I'd want to see about finding commonalities, and build a piece which makes these kinds of integrations easier
[22:46] <hpottinger_> pretty sure Corisco and OhioLink both just use the DBs directly
[22:51] <mdiggory> what do you have in mind for details you want to cover?
[22:51] <mdiggory> "Disseminator Framework"?
[22:53] <mdiggory> Well, TBH, the tried/true approach for anything we integrate for a client is XMLUI Aspects for presentation and Consumers or Mediafilters for processing.
[22:56] <hpottinger_> sorry, wandered off a bit there, still formulating ideas, but if you have ideas for how best to approach, I'm all ears
[23:01] <hpottinger_> aha, Disseminator Framework, yes, cool
[23:03] * tdonohue (~tdonohue@c-24-13-90-87.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:10] <hpottinger_> the GSoC wiki page for ideas is full of, erm, great ideas
[23:17] * hpottinger_ (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.
