#duraspace IRC Log

Index

IRC Log for 2012-01-04

Timestamps are in GMT/BST.

[6:35] -zelazny.freenode.net- *** Looking up your hostname...
[6:35] -zelazny.freenode.net- *** Checking Ident
[6:35] -zelazny.freenode.net- *** Found your hostname
[6:35] -zelazny.freenode.net- *** No Ident response
[6:35] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:35] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:35] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:03] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:19] * elschlomo (4e2a62d3@gateway/web/freenode/ip.78.42.98.211) Quit (Quit: Page closed)
[17:42] * barmintor_home (barmintor@specdl11.cul.columbia.edu) Quit (Ping timeout: 244 seconds)
[19:39] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) has joined #duraspace
[20:06] <mhwood> Is there a meeting today? (Maybe not: the agenda page (which I forgot to update for the 21-Dec meeting -- sorry) still says 07-Dec.)
[20:06] * richardrodgers (~richardro@18.111.4.203) has joined #duraspace
[20:07] <richardrodgers> hmm, doesn't look like a committer mtg today?
[20:09] <richardrodgers> Happy new year all, in any case!
[20:09] <mhwood> Perhaps not: the agenda page still says 07-Dec.
[20:10] <richardrodgers> mhwood: I know Tim was trying to recruit a stand-in, not sure if he succeeded..
[20:13] <richardrodgers> I'll post to the dev list before next week's slot to see if there is appetite to pick up again. Bye
[20:13] * richardrodgers (~richardro@18.111.4.203) Quit (Quit: richardrodgers)
[20:20] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) Quit (Quit: KevinVdV)
[20:41] * PeterDietz-alt (~dspace@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:43] <PeterDietz-alt> Hi All, sorry by my terrible attendance as of late. Networking is an absolute nightware on my new work computer... e1000e constantly drops me.
[20:45] <PeterDietz-alt> locally, I've found it to be very useful to add a function to DSpaceObject called getTypeText(), so that you can get the word BITSTREAM, COLLECTION, etc, instead of having to do Constants.typeText[dso.getType()]
[20:50] <mhwood> Oh, great: I just ordered an e1000e yesterday.
[20:51] <mhwood> DSObject.getTypeText() sounds like a good idea -- other code shouldn't have to know how to make the translation.
[20:51] <mhwood> BTW you are only the third person to actually say something here since 0803 ET. I think there's no meeting set up today.
[20:52] <PeterDietz-alt> public String getTypeText() { return Constants.typeText[this.getType()]; }
[20:52] <PeterDietz-alt> its still on my busy-time on my OSU calendar.. and.. I'm still late
[20:53] <mhwood> About what I expected. This is a good time to propose deep-down stuff like that, with 3.0 presumably about to start...unless 3.0 changes make it irrelevant somehow.
[20:54] <mhwood> Yes, the DSpace shared calendar has meetings every week, including this one. The agenda page hasn't been updated since 07-Dec though.
[20:56] <mhwood> Looks like I dropped the baton on the 21st, as I didn't ask for a volunteer to take it for 28th or today.
[20:58] <PeterDietz-alt> deep down cuts sounds good. Replacing everything with Services still feels foreign to me...
[20:58] <PeterDietz-alt> But I was trying to swap out solr in favor of mongoDB, and xmlui had some serious hardcoded dependencies on SOLR
[20:59] <mhwood> I do wonder why we have quite so much complexity in Services, instead of just deciding to become a Spring app. or some such and letting *that* framework handle the wiring.
[21:02] <mhwood> Hmmm, one place too much(?) abstraction, the other not enough.
[21:02] <PeterDietz-alt> so chicken verse egg.. Do we clean up DSpaceObject, Community, Collection, MetadataValue, DCValue[], etc... or switch to relying upon the service, and whoever implements the service has to clean things up
[21:03] <mhwood> Really the same thing, no? Either revise the contracts for DSpaceObject et al. or write equivalent contracts into new interfaces for those Services.
[21:04] <mhwood> And I think there was some desire to coin interfaces off the existing classes to facilitate Service-izing...we need some decisions.
[21:05] <PeterDietz-alt> call me a legacy application maintainer guy, but I'm more interested in additional functionality like metadata-for-any-DSO, or versioning-of-bitstreams, than I am in swapping out entire backend for "mystery" alternative
[21:09] <mhwood> I tend to be incrementalist on things like moving to Services (maybe you noticed). If a DSOService is desirable, and we could do that as part of revising the contract, then go for it. Re-orienting the entire codebase to Services all at once feels like too big a chunk of time spent not working on stuff that the user actually sees.
[21:11] <mhwood> OTOH DSpace is written in an OO language but often in very non-OO ways, and in some cases that makes improvements more difficult than they should be. We could get more from Java.
[21:12] <mhwood> I know I've seen examples but can't think of specific ones just now. :-/
[21:23] <mhwood> I do worry whether we spend too much time on rearranging the guts of DSpace vs. making it a sharper, more capable tool.
[21:25] <PeterDietz-alt> So long as the areas a local-developer might be interested in touching are clean enough (i.e. curation tasks), vs things that are not touched by anyone org.dspace.core.Collections
[22:07] <mhwood> Must go. 'bye!
[22:07] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[23:24] * PeterDietz-alt (~dspace@sul272sandbox.lib.ohio-state.edu) Quit (Quit: Leaving)

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