Timestamps are in GMT/BST.
[6:51] -pratchett.freenode.net- *** Looking up your hostname...
[6:51] -pratchett.freenode.net- *** Checking Ident
[6:51] -pratchett.freenode.net- *** Found your hostname
[6:51] -pratchett.freenode.net- *** No Ident response
[6:51] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:51] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:51] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:57] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[12:03] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:02] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[13:34] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Quit: Leaving)
[13:34] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[14:40] * tdonohue1 (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[14:40] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Disconnected by services)
[15:10] * misilot (~misilot@p-body.lib.fit.edu) Quit (Ping timeout: 248 seconds)
[15:10] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[15:13] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[15:16] * misilot (~misilot@p-body.lib.fit.edu) Quit (Remote host closed the connection)
[15:19] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[15:20] * misilot (~misilot@p-body.lib.fit.edu) Quit (Remote host closed the connection)
[15:22] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[15:40] * gravelpot (~gravelpot@128.83.231.140) has joined #duraspace
[15:53] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[15:57] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[16:02] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[16:02] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[16:02] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[17:36] * PeterDietz (~peterdiet@128.146.173.70) Quit (Remote host closed the connection)
[18:17] * jrgriffiniii (~chatzilla@139.147.64.81) has joined #duraspace
[18:28] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:46] * bram-atmire (~bram@94-225-36-191.access.telenet.be) has joined #duraspace
[19:51] <tdonohue1> Hi all...reminder that our DSpace Dev Mtg will be starting at the top of the hour: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-03-27
[19:53] <bram-atmire> Hi
[19:58] * tdonohue1 is now known as tdonohue
[20:01] <tdonohue> Hi all...it seems like it's been a while (at least for me), but I'm finally back from traveling, etc. to attend a normal DSpace Developers Mtg :)
[20:01] <tdonohue> Our agenda for today is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-03-27
[20:02] <tdonohue> I decided to forgo any JIRA reviews for today, as there's a lot to catch back up on...but, we'll start the JIRA backlog hour again next week
[20:02] <tdonohue> So, the first topic I had for today was just to talk about the DuraSpace Sponsor Summit....
[20:03] <tdonohue> You probably already saw all the notes/slides/summaries floating around (also linked off agenda).
[20:03] <tdonohue> I just wanted to give us a chance to discuss any questions/concerns/ideas you may have?
[20:03] <tdonohue> or general comments, etc. Just want to make sure everything seems clear to you all
[20:04] <helix84> so was the target group about the same as the target group of the Futures call?
[20:05] <tdonohue> no..this target group was DuraSpace sponsors in general. So it included DSpace & Fedora users both. Audience was a mix of University Library folks, Repo Manager folks, IT director folks, and some general tech folks.
[20:06] <helix84> ok, thanks
[20:06] <tdonohue> There was a breakout session (the second day) to discuss DSpace specifically, amongst those that use DSpace. In that session there were some folks who'd been on Futures calls (a few DCAT folks...I was the only Committer there though)
[20:06] <bram-atmire> Tim, was it your impression that the audience was well aware of all the improvements part of DSpace 3
[20:06] <bram-atmire> and the big influx of new contributions there was
[20:07] <bram-atmire> The community & amount of contributions is bigger than ever right? But still it feels like the shrinking of the fedora community
[20:07] <bram-atmire> somehow "contaminates" people's impression about DSpace
[20:07] <tdonohue> Yes, I think they were aware of the big influx of contributions around DSpace 3. I recall that being mentioned a few times.
[20:07] <bram-atmire> or is that a wrong assumption?
[20:08] <tdonohue> I think folks in general felt that the DSpace community is more active than e.g. Fedora (no offense to them) and that activity is great
[20:09] <tdonohue> But, the concerns expressed were that, despite that great activity & influx of features in DSpace 3, there are still some larger (mostly architectural) internals in DSpace that are harder to change..and may require more $$ / resources than we have
[20:09] <tdonohue> There also were concerns about the lack of a longer term "vision" for DSpace (e.g. what will/should it look like in 5 years, and how can we move towards that in a planned fashion)
[20:09] <helix84> expressed by duraspace towards the attendees or vice versa?
[20:09] <mhwood> I think maybe some of them just take a decision, and perhaps more work breakdown that we've had.
[20:10] <helix84> sorry mhwood, i didn't understand what you said
[20:10] <tdonohue> helix84: both. but mostly from the attendees to DuraSpace saying that they love DSpace, yet they wish it could more quickly improve it's internals/architecture and become easier to work with (in terms of theming it, add-ons, etc)
[20:11] <tdonohue> Essentially, there are a few interweaving issues here...which I can try and summarize briefly (the notes/slides go into much much more detail though, if you want it)
[20:12] <helix84> thanks, speaking for myself, i've read it and what i wanted to know i just asked
[20:13] <tdonohue> 1) The DSpace Open Source project has a great number of contributors & volunteers working for it...but, as a whole, it's a bit "underfunded" (DuraSpace is "losing money" on it...we are providing it more staff than we are getting in donations/sponsorship $$)
[20:13] <mhwood> helix84: well, on some issues we need to decide "we are going to do this and it's going into 5.0" (e.g.).
[20:13] <tdonohue> 2) At the same time, the DSpace Community (or at least the attendees at this Summit) feel that the software needs some "Extra love" / modernization in the near(ish) future, which may require extra funding/resources to make it happen
[20:14] <mhwood> helix84: In other cases we need to pull large ideas apart into sets of more manageable ones, get various people to take pieces, and schedule the pieces.
[20:15] <tdonohue> 3) And, it'd also be good to come up with a common "vision" for what DSpace may look like in 5 years (amongst the community) . So, we can make sure we have something to try and encourage folks to donate extra $$ / resources
[20:15] <tdonohue> I think that's the 4000 foot view, essentially
[20:15] <helix84> mhwood: thanks, agreed
[20:16] <helix84> tdonohue: I think that's a great comment - that we should have a plan/vision to present in order to get $/resources
[20:16] <tdonohue> But, honestly... as mentioned, I did feel the Summit was "inspiring". Folks from all over do care a lot about DSpace...and everyone wants to see the project continue to succeed. It's just time to take a step back and see if we need extra $$/resources to do so.
[20:17] <hpottinger> so, we need to define what DSpace is now (good points and bad) and what we'd like it to look like in the future
[20:17] <mhwood> $$ is nice to have available. As one of the resources, though, I tend to think first of donating resources as someone here saying, "Mark, this feature is important to the University. We want you to pitch in and help make it happen."
[20:17] <tdonohue> helix84: yea..exactly. That's the feedback we got from attendees....we need a "vision" to get $$ or more resources
[20:18] <helix84> if I may comment on that, what I see is that we've been getting a lot code contributions recently, the problem being commiter bandwidth, IOW people testing the patches and pushing to commit them
[20:18] <helix84> i.e. not necessarily (just) money
[20:19] <mhwood> That touches on something I brought up a while ago: periodic pull-request review.
[20:19] <helix84> one direction we may need to work in is to get people test each other's code so that we can just ACK and commit code that has been already field-tested
[20:19] <bram-atmire> true - i wonder how they cope with this when developing the core of a bigger OSS project
[20:19] <tdonohue> One of the next steps is that DuraSpace is going to bring together a small group (<15 folks) in Chicago sometime in the near future (May) to start to *draft* a vision statement. It's gonna be a small group, just cause it'd be hard to do with too many folks. And the draft would then be posted publicly for comment/revision for everyone.
[20:20] <helix84> brb
[20:20] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[20:21] <tdonohue> I agree about the pull-request review comments...it's just hard for us to find the bandwidth for all this in our meetings... JIRA reviews, Pull request reviews, release planning, other stuff that comes up. It's getting hard to fit in 1 hr per week.
[20:22] <hpottinger> I do agree that shared vision and focus would be one way to tackle the "bandwidth" problem, if our institutions support our focus on a project, we can carve out the time to work on the project
[20:22] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[20:22] <tdonohue> hpottinger: true
[20:23] <hpottinger> my biggest conflict for my time comes from the fact that I work in a library, and am asked to work on other programming/devops things, I can't really focus all the time on DSpace
[20:24] <hpottinger> one thing to keep in mind, though, is that adding more developers and $$ doesn't necessarily lead to greater available bandwidth
[20:25] <bram-atmire> that's true
[20:25] <helix84> +1
[20:26] <tdonohue> Agreed. A second part of this is that a few higher ups (University Librarians) are going to propose some possible new "Governance" for DSpace. Something like a possible "steering committee" and maybe a true "product manager" role (My role is like 1/2 product mgr and 1/2 techie right now).
[20:27] <tdonohue> I don't know what that Governance would look like... But I think everyone agrees it needs to include the existing Committers (and DCAT)
[20:28] <helix84> hmm, i'm not sure that is the direction we need to work in (although i'm not necessarily opposed)
[20:28] <tdonohue> So..that's something else that may be coming in the next year or so...again though, you all will see a public draft before anything would happen (and I'd also want to call a vote)
[20:28] <bram-atmire> I think this kind of people would have a great overview of all software living inside the library infrastructure
[20:28] <bram-atmire> and might be able to spot interesting gaps or needs where DSpace can play a role
[20:29] <helix84> can you please explain what the goals of such governance would be? i.e. how it would translate to more work being done on DSpace?
[20:29] <bram-atmire> but that's just coming from the fact that I don't actually work in a library and you guys do
[20:29] <hpottinger> mostly we develop to scratch our own itches now, and then share the good stuff… it would be interesting to see where the governance idea leads
[20:30] <bram-atmire> Even in DCAT, it's hard to form a good opinion on issues like:
[20:30] <helix84> actually, if their job would be to secure resources (internal and external) towards particular projects, then I'm all for it
[20:30] <tdonohue> helix84: That's all TBD, to be honest. I have some vague brainstorms myself that I could try to explain. I personally think the role of the "steering committee" would be to keep a "vision" in mind and help us to find resources towards that vision. A "product manager" would help organize those resources to make the vision happen.
[20:30] <bram-atmire> just how important is it for DSpace to be on the Linked Data vibe in the next few years?
[20:31] <helix84> bram-atmire: ask Sands Fish about that ;)
[20:32] <tdonohue> So...essentially, these are all the "big topics" that were floating around at this DuraSpace Summit. There's a lot that's TBD...and I'll obviously keep you all informed / in the loop. I'd also put any "drafts" in front of all of you early for comments/concerns.
[20:33] <tdonohue> Does this all make some general sense? Are there other immediate questions? (yea, I know it's not all crystal clear...it's not all 100% clear in my mind either...I just have brainstorms floating around.)
[20:35] <mhwood> Makes sense to have some entity asking, from time to time, "is there progress on Big Idea X?"
[20:35] <tdonohue> But, rest assured..I don't think Committership is gonna change. Committership will still be merit-based. So, any bigger initiatives will need some level of Committer approval/involvement.
[20:35] <bram-atmire> makes sense - overall enthusiastic that the higher ups want to put their shoulders under DSpace as well in this way
[20:35] <helix84> i just wanted to say thanks, Tim, for keeping us informed _early_ and also for all the work you've been doing to keep things oiled up - when you've been missing the DevMtgs were, well, different :)
[20:36] <tdonohue> I try to do my best :)
[20:36] <tdonohue> Ok. Well, in the essence of time, I'm gonna move along. If you have other questions or brainstorms around these "big topics", please feel free to send them my way.
[20:37] <tdonohue> Next on the agenda: GSoC 2013. We won't be applying this year...just seems like we all don't have enough bandwidth. It's a shame, but it's reality, so there's not much to do about that!
[20:38] <tdonohue> hopefully we can find more bandwidth next year
[20:38] <bram-atmire> if we can't assure that with the right coaching, the code has a good chance to make it into the core, it's tough to justify all the effort
[20:38] <helix84> i know i'm too late, i just wanted to say that i was willing to mentor a project or two - nothing in particular. i think we could have reused some ideas from last year.
[20:38] <bram-atmire> that comes along with this
[20:39] <hpottinger> We have a student worker here, I intend to task him with my one idea for GSoC, and see what he comes up with
[20:40] <tdonohue> yea..at this point, I think it's too late for GSoC 2013. Applications are due Fri...I've got a day of mtgs tomorrow (Thurs) and am on vacation on Fri. Plus, I think I was really hoping to find a good 3-4 possible mentors, to ensure we could do some "co-mentoring" on projects that may have needed it
[20:40] <tdonohue> but, again..no worries. We'll try again next year. I think this year just wasn't a good match
[20:41] <tdonohue> Next topic on agenda...just some general updates on the 3 new initiatives (being loosely called "DSpace Futures", though that's probably not the best name for them)
[20:42] <tdonohue> REST API, Metadata improvements proposal...and those Hydra + DSpace brainstorms.
[20:42] <tdonohue> I just wanted to touch base on what we (DuraSpace) has heard back.
[20:43] <tdonohue> First, REST-API - We had a few institutions who are interested in helping with this. Namely Harvard seems very interested in seeing this happen soon (they are wanting to build some "javascript widgets" on the REST API to embed DSpace content in other websites)
[20:43] <tdonohue> U of Manchester is also interested in REST-API help.
[20:44] <tdonohue> I know most of us are also interested in seeing the REST-API happen (as we discuss it a lot!)
[20:45] <tdonohue> So, it seems like we may need to try and find a way to push this REST-API stuff forward. I'm trying to determine the best way to do so (ideas/volunteers welcome). I'd love to see this in 4.0, if we can make it
[20:45] <hpottinger> I think the Hedtek REST-API was running on demo a while back
[20:45] <mhwood> What is yet to be done?
[20:46] <tdonohue> So, I guess the big question is here...anyone have bandwidth towards this in the near(ish) future? we definitely have others (Harvard & Manchester) willing to help out however they can.
[20:46] <bram-atmire> basically the hedtek REST-API and the Lyncode/Wijiti one are completely separate implementations, right?
[20:46] <bram-atmire> http://lyncode.github.com/dspace-rest-api/ and https://github.com/hedtek/dspace-rest
[20:47] <tdonohue> to be done: Decide which REST-API is "official". Start to test it out & fix any bugs it may have. There's also a list of "use cases" folks have brainstormed for a REST-API. We'd want to see if we can meet many/most of these: https://wiki.duraspace.org/display/DSPACE/DSpace+Futures+REST+API+Use+Cases
[20:47] <hpottinger> I'm planning to put Hedtek REST-API through its paces in a week or so
[20:47] <helix84> lyncode just uses the wijiti API (AFAIK)
[20:47] <helix84> i think they wrote some docs, though
[20:47] <bram-atmire> helix84: that was my impression as well
[20:47] <helix84> so we have 3 implementations
[20:48] <helix84> the original gsoc project (not kept up to date)
[20:48] <tdonohue> hpottinger: demo.dspace.org is running Hedtek (PeterDietz put it up there). It's linked off the main page
[20:48] <helix84> and the wijiti and hedtek implementations, both building on the original gsoc project in different ways
[20:49] <mhwood> What do we need in order to pick one and move forward?
[20:49] <hpottinger> tdonohue: I can't find the link on the main page of demo…
[20:49] <helix84> the hedtek version was done as contract work by Hedtek for Jorum
[20:49] <tdonohue> I'd say we'd "throw out" the old GSoC project. It was a great "foundation", but I'd venture to guess that Wijiti and HedTek are both more usable/reasonable at this point
[20:49] <tdonohue> hpottinger: scroll down, under "Third Party Interfaces": http://demo.dspace.org/
[20:50] <helix84> but i've been talking to both projects and Jorum is leaning towards also switching to Wijiti (because we need to choose one) and Wijiti is more feature-complete (Hedtek is read-only)
[20:51] <helix84> I was speaking about Hedtek being a contractor because they are not intriniscally interested in continuing work on their implementation (because the funding was tied to the project)
[20:51] <hpottinger> read-only is cool for my use case (similar to Harvard's, I need to have a chat with them)
[20:52] <helix84> hpottinger: about Hedtek API, speak to Ben Ryan from Jorum
[20:52] <tdonohue> The feedback I've heard so far is essentially: Wijiti is more feature-complete (read/write)... but Hedtek is highly scalable (or at least claims to be) and read-only is actually good enough for data reuse.
[20:53] <hpottinger> maybe we need a wiki page for REST-API stuff?
[20:53] <helix84> the current problem is that there is almost nobody who has worked with _both_ implementations, that's why it's difficult for us to tell which one is "better" and pick one
[20:53] <helix84> but hopefully I'll have some feedback from Jorum by next week
[20:53] <helix84> hpottinger: they have both their documentation online
[20:54] <helix84> there's also docs for the original gsoc project
[20:54] <mhwood> So, readonly is "good enough". Is scalability valuable? writability?
[20:55] <hpottinger> helix84: I was thinking more of a place where conversations like this could take place, the whole community could see who's is working on what, etc.
[20:55] <helix84> so, to sum up the very latest development, it seems Jorum is leaning in the direction of Wijiti and Wijiti is commited to continue development, while Jorum/Hedtek is not necessarily going to work on Hedtek API
[20:55] <helix84> hpottinger: yea, it's very much in flux, so it would be hard to keep up to date
[20:55] <tdonohue> the only real discussion "wiki" page on REST API is the pages linked off here: https://wiki.duraspace.org/display/DSPACE/DSpace+Futures
[20:56] <bram-atmire> ow, so this one may be deprecated? https://wiki.duraspace.org/display/DSPACE/REST+API
[20:56] <helix84> yeah, that's more like a vision, not much to do with the current implementations :)
[20:58] <tdonohue> For what it's worth, my view is as follows: Wijiti seems to be getting more folks using it (and have better support), so it might be the best option. But, we'd want to make sure it is *secure* (i.e. needs authentication for 'write' privileges) and hopefully decently scalable. The main benefit to Hedtek right now is the scalability and it's highly secure (read-only) -- but it's detriment is you cannot write data via it, you'd
[20:58] <helix84> I agree. Our problem right now is that we have data on who uses what, which doesn't necessarily indicate which one is better technically.
[20:59] <helix84> We really need feedback from people who have used both implementations
[20:59] <tdonohue> bram-atmire: That old REST API wiki page just describes the old GSoC project...it would be "deprecated"
[20:59] <hpottinger> I think it would be worthwhile to try to exchange this info, if the Futures page included and invitation to add your own info, I'd feel more comfortable doing so
[20:59] <mhwood> Can we just pick one and learn from the other as we go?
[20:59] <tdonohue> hpottinger -- add it! :)
[21:00] <bram-atmire> tdonohue: on the page there was some info on the wijiti work, but maybe that's all that got added to the page
[21:00] <bram-atmire> in 2012
[21:00] <tdonohue> mhwood: sure we could just choose one. We just wouldn't want to pick one that poses a security risk (obviously).
[21:01] <hpottinger> I think it would be worthwhile to port the acceptance testing parts of Hedtek's implementation to wijiti's
[21:01] <tdonohue> bram-atmire: oh, didn't see that. yea, that may be all that's been added. Most of that "REST API" page may be outdated though
[21:02] <mhwood> We just need to make sure that it is secure by the time it goes out the door.
[21:02] <helix84> hpottinger: agreed. we're not sure yet how much the actual API s of the two implementations differ, but if there are any differences, they shouldn't be large.
[21:02] <tdonohue> mhwood - correct, obviously :)
[21:02] <mhwood> Either one is going to continue to be incomplete until we complete it.
[21:03] <hpottinger> I suspect Jorum would be interested in maintaining the tests, too
[21:03] <mhwood> So what it boils down to is: which would we better like completing?
[21:03] <helix84> yes, which one is the better starting point
[21:03] <tdonohue> mhwood: yea... maybe that argues for Wijiti (as it comes with some hint of support, and people are moving towards it) and just bang on it, and port stuff from Hedtek over?
[21:04] <mhwood> Sounds like a plan!
[21:04] <hpottinger> I do remember someone pointing out that wijiti and hedtek share ancestry
[21:05] <tdonohue> hpottinger -- they do...that ancestry is the GSoC project ... but since then they've forked completely
[21:05] <hpottinger> But, honestly, if Jorum is moving to wijiti, it sounds like somebody in the community has already voted with their feet
[21:05] <tdonohue> hpottinger - so the codebases may or may not be that similar today
[21:06] <hpottinger> mhwood's plan: +1
[21:06] <mhwood> OK, I move that we adopt wijiti as official and study Hedtek for good ideas we want to port.
[21:06] <tdonohue> hpottinger: very good point. If the folks behind hedtek are moving to wijiti, that says something
[21:06] <helix84> they're getting their feet wet - not working on it full time because they're working on upgrading to newer versions of DSpace
[21:06] <hpottinger> mhwood: +1
[21:06] <tdonohue> helix84: thanks for correcting that.
[21:07] <helix84> i'd still wait to hear from their developer, who would be the rare preson who has tried both
[21:07] <tdonohue> mhwood: +1 too. (though wondering if we may want to hold a vote amongst more folks...on -commit? on -devel?)
[21:07] <tdonohue> helix84 -- have you gotten in touch with their developer
[21:07] <tdonohue> ?
[21:08] <tdonohue> (argh...that "?" was meant for the previous line)
[21:08] <mhwood> Vote on ML if you want to. I just want to stop talking about which one? which one?
[21:08] <helix84> no, only with Ben, who is more like a project manager
[21:08] <tdonohue> mhwood : agreed. +1000
[21:09] <mhwood> So, discusson: call for a vote? on -devel? -commit? here?
[21:09] <hpottinger> I vote, vote now
[21:09] <tdonohue> my only issue with voting here, now...is that there seem to be only 5? of us here today (hpottinger, helix84, mhwood, bram-atmire, me)
[21:10] <helix84> I'm sorry guys but it seems to me we're not being rational here
[21:10] <helix84> the reason we're talking about it again and again is that nobody has done actual comparison
[21:10] <helix84> what you're proposing is just to get it over with without considering actual technical merit
[21:11] <helix84> what I was trying to do is get an informed opinion
[21:11] <helix84> yes, it has been taking long
[21:11] <hpottinger> :-) OK, apologies to those not present, I revise my vote to: vote on -devel
[21:12] <helix84> I feel bad I have to point that out but I just wanted to give one last warning before the herd mentality takes over :p
[21:12] <tdonohue> I'm fine with getting informed opinion, if we can get it. I think what we've been suggesting here is that people are beginning to migrate to Wijiti (which says something). Currently, in general though what we are lacking is volunteers.
[21:12] <mhwood> It was sounding to me like we'd got all the informed opinion available and are just weathervaning. But I have been wrong before.
[21:13] <mhwood> There won't be volunteers until they know for what they are volunteering.
[21:14] <helix84> right now we need volunteers to try out both :)
[21:14] <bram-atmire> are the docs on wijiti/lyncode also visible without installing it?
[21:15] <helix84> yes
[21:15] <tdonohue> If we wait for more feedback, we need volunteers to actually do the comparison. If we just choose what seems to be popular (Wijiti), we'd still need volunteers to bang on it, help improve it, and merge into our codebase.
[21:15] <helix84> http://lyncode.github.com/dspace-rest-api/
[21:15] <hpottinger> I don't often look at the list of attendees, and it seemed like we were having lively discussion, but, seriously, if we have two vendor-written APIs, and only one has a vendor committed to backing it up, and Jorum is planning to move from one API over the other…
[21:15] <bram-atmire> well, there it says: After starting the REST API, visit the base url: http://<yourdomain>/rest, it will show the API documentation.
[21:16] <hpottinger> anyone have the bandwidth to set up wijiti on demo?
[21:16] <tdonohue> not I, but I'd encourage someone to do so
[21:16] <helix84> hpottinger: i agree with you, except one consideration - what if the other one is a better starting point? the one that we bless as official will be what everyone will move on regardless of the current trend.
[21:17] <tdonohue> Getting both setup on demo.dspace.org would be a good way to allow folks to play with either a bit
[21:17] <mhwood> The one we bless will be better when we are finished with it, I hope. If they are so close now that we can't decide, how poor a choice can we make?
[21:17] <helix84> tdonohue: +1000
[21:18] * tdonohue notes we're obviously well over time here (and a bit off our agenda...but it's been lively discussion)
[21:18] <mhwood> By all means demo it, but don't wait for something that is waiting for us.
[21:18] <hpottinger> if hedtek version is a better starting point, we'd be taking on two big things: total support of the code, and adding write support
[21:18] <helix84> we just can't decide because we didn't try them, not because they're tied for lead in excellence :)
[21:20] <bram-atmire> need to go, see you
[21:21] <helix84> there is still one factor we didn't mention today
[21:21] <helix84> IIRC, wijiti is updated to DSpace 3.0. I'm not sure about Hedtek.
[21:21] <tdonohue> So, one quick way to help others review both would be to get both on demo.dspace.org....we could then ask for help in reviewing them (or have folks vote somewhere). Just an idea...but it requires someone to get Wijiti installed on demo.dspace.org (I won't have time in the next week or two, unfortunately..swamped here with DSpaceDirect.org soft-launch)
[21:22] <hpottinger> helix84: hedtek is running on Demo right now, which is on 3.1
[21:22] <tdonohue> helix84: Hedtek is running on demo.dspace.org right now, against DSpace 3.1. So, it can at least communicate with dspace 3.
[21:22] <helix84> ah, ok, thanks
[21:23] <tdonohue> any volunteers here to try and get Wijiti installed on demo? Or anyone else in committers we could ask (Joao maybe? since Lyncode has that easy-installer?)
[21:24] * bram-atmire (~bram@94-225-36-191.access.telenet.be) Quit (Quit: bram-atmire)
[21:24] <helix84> i wanted to try wijiti, but i can't promise i'll have time
[21:24] <helix84> yes, we could ask joao
[21:26] <tdonohue> ok...just wonder if even that would get us a better sense of which "looks better". I'll admit, I still have begun to lean towards Wijiti, cause of the support and based on what we've heard from others so far.
[21:29] <tdonohue> unfortunately, I'm gonna have to head into lurking here shortly. Obviously we're well over our normal meeting time. I think we all seem to be leaning more towards Wijiti REST API...but are still open to more feedback / help from others
[21:29] <helix84> woo, demo has a new frontpage
[21:29] <mhwood> Gotta go. Thanks!
[21:29] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:29] <tdonohue> that was PeterDietz's doing. He was playing with it when he went and installed the Hedtek REST API on demo
[21:29] <tdonohue> (this was a few weeks back)
[21:30] <helix84> yeah, he keeps saying how busy he is yet he does all the work on DSpace these days - the ES statistics, Hedtek on demo, a new frontpage on demo... :D
[21:30] <hpottinger> yeah, PeterDietz deserves a rousing HUZZAH! for that work.
[21:43] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:44] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[21:52] * tdonohue (~tdonohue@c-67-177-111-99.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.