Timestamps are in GMT/BST.
[6:49] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[6:53] -asimov.freenode.net- *** Looking up your hostname...
[6:53] -asimov.freenode.net- *** Checking Ident
[6:53] -asimov.freenode.net- *** Found your hostname
[6:53] -asimov.freenode.net- *** No Ident response
[6:53] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:53] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:53] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:58] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[6:58] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[6:58] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[10:30] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[11:14] * eddies (~eddies@42.61.209.30) has joined #duraspace
[11:14] * eddies (~eddies@42.61.209.30) Quit (Changing host)
[11:14] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:06] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[12:13] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:50] * eddies (~eddies@cm107.eta98.maxonline.com.sg) has joined #duraspace
[12:50] * eddies (~eddies@cm107.eta98.maxonline.com.sg) Quit (Changing host)
[12:50] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[12:58] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[18:35] * hpottinger (~hpottinge@mu-161251.dhcp.missouri.edu) has joined #duraspace
[18:47] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[18:59] * bram-atmire (~bram@94-225-35-170.access.telenet.be) has joined #duraspace
[19:01] <bram-atmire> hi
[19:01] * hpottinger waves
[19:31] * bollini (~chatzilla@host175-48-dynamic.247-95-r.retail.telecomitalia.it) has joined #duraspace
[19:38] * ruebot_ (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[19:40] * ruebot_ (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Client Quit)
[19:40] * ruebot_ (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[19:42] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) Quit (*.net *.split)
[19:57] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:01] <tdonohue> Hi all, it's time for our weekly DSpace Developers Meeting
[20:02] <tdonohue> I had an agenda, but as several other topics came up in #dspace today, wondering if we should mostly concentrate on those topics
[20:02] <tdonohue> Just plugged those into my agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-05-22
[20:02] <kompewter> [ DevMtg 2013-05-22 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-05-22
[20:03] <tdonohue> Ok. first up though a few PR reviews...looking up where we left off
[20:03] <mhwood> Agenda says 154
[20:04] <tdonohue> agenda is wrong actually...we did 154 & 159 last week....sorry, neglected to update agenda
[20:04] <tdonohue> https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:04] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:04] <tdonohue> today we start at #161: https://github.com/DSpace/DSpace/pull/161
[20:04] <kompewter> [ DAO Implementation (Status: 50%) - Community help requested by lyncodev · Pull Request #161 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/161
[20:05] <tdonohue> Joao's DAO work, related to DS-1438
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-1438 ] - [#DS-1438] DAO implementation - DuraSpace JIRA
[20:06] <tdonohue> so, this seems to be sitting "static" now for ~5months. What can we do to move this forward?
[20:06] <helix84> not so many people commented
[20:07] <helix84> and there was also a request to implement the missing methods
[20:07] <mhwood> Resolve the issues around smooshing Services into API?
[20:07] <tdonohue> it looks like the last comment from mdiggory to the PR was to try and "split" up the work incrementally (to make it easier to review).
[20:08] <mhwood> I like that approach.
[20:09] * hpottinger wonders if we figure out a way to nudge PR submitters that their PR will be on the agenda a certain week?
[20:09] <mhwood> I echo mdiggory's concerns about dependency tangles.
[20:09] <tdonohue> I also do. I freely admit, I have a very hard time reviewing "huge" pull requests. I know we all do this on occasion, but it makes it harder to tell what is going on / being changed, without some clear docs/explaination
[20:10] * ruebot_ (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Quit: Please, sir, I want some more.)
[20:10] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) has joined #duraspace
[20:10] * ruebot (~ruebot@ec2-50-112-50-181.us-west-2.compute.amazonaws.com) Quit (Changing host)
[20:10] * ruebot (~ruebot@pdpc/supporter/professional/ruebot) has joined #duraspace
[20:10] <tdonohue> hpottinger: Nice idea...not sure how to do it without a lot of "guessing". Some weeks we get through 3-4 PRs..others, we are lucky to finish one
[20:10] <helix84> yes, for instance, the discovery enhancements for 3.0 which packed many things ina single PR were impossible to review completely. only now we're dealing with things it introduced - like provate items.
[20:11] <tdonohue> helix84: exactly
[20:11] <helix84> i'm all for incremental improvements
[20:11] <PeterDietz> i ran into some services woes this week. How to make an outside App talk-DSpace. I think without Joao's work, you can't get context via Services. I honestly have idea what instantiated it for me
[20:11] <bram-atmire> It kind of comes down to who takes it up to create a good test protocol for these kinds of bigger things
[20:11] <helix84> but first of all, we need to approve those suggestions
[20:11] <mhwood> Back when I lurked on the Linux kernel ML, it was not uncommon to see a patch rejected with "nice work, but break it down into small pieces that can be reviewed individually."
[20:12] <bram-atmire> Someone willing to do a review, should need to look at all individual lines of code and figure out for him/herself what the impact is
[20:12] <helix84> in particular, does anyone have problem with step 1) merge dspace-services?
[20:12] <bram-atmire> should *not
[20:12] * l_a_p (~chatzilla@93-57-61-229.ip163.fastwebnet.it) has joined #duraspace
[20:12] * bollini_ (~chatzilla@host11-63-dynamic.245-95-r.retail.telecomitalia.it) has joined #duraspace
[20:13] <tdonohue> merge dspace-services: Not a problem to me. Though mdiggory's response was that he didn't think that was necessary.
[20:13] <mhwood> PeterDietz: is it necessary to have a service for this? Just "new Context()" when you need one. (But services must be running first.)
[20:14] <PeterDietz> I think I'm in favor of that. But what does services DSpace kernel .stop() mean? Is that when the JVM shuts down, or when an app using the DSpace Kernel shuts down.. Services in the whole confuses me, maybe it will confuse me less if its sucked into the dspace-api
[20:14] <helix84> tdonohue: i'm confused, because it was his suggestion (step 1) but nice to see the discussion around this starting!
[20:14] <mhwood> There's a listener to take care of kernel lifecycle.
[20:15] <bram-atmire> in joao's documentation he mentions the need for services migration: https://wiki.duraspace.org/display/~joaomelo/DAO+Implementation
[20:15] <kompewter> [ Log In - DuraSpace Wiki ] - https://wiki.duraspace.org/display/~joaomelo/DAO+Implementation
[20:15] <bram-atmire> "dspace-services merged into dspace-api: The need for it is to allow DSpace util class (dspace-services) to support getContextService method, which uses Context (dspace-api class)."
[20:15] * bollini (~chatzilla@host175-48-dynamic.247-95-r.retail.telecomitalia.it) Quit (Ping timeout: 260 seconds)
[20:15] <PeterDietz> new Context() is ultimately: connection = DatabaseManager.getConnection();
[20:15] * bollini_ is now known as bollini
[20:16] <tdonohue> in any case, I'm not adamantly against moving dspace-services into dspace-api. It's ok.
[20:16] <PeterDietz> I don't think any app wants to get into the business of concerning about the context. If you have the DSpace Kernel, then you should be all set
[20:17] <mhwood> Alternative: move Context into services.
[20:18] <PeterDietz> I don't have strong feelings on the matter. Maybe consolidation sounds cleaner...
[20:19] <tdonohue> It seems like none of us have strong feelings on this.
[20:19] <tdonohue> I suspect though that many of us would LOVE DAO (Or at least I've heard it a lot). So, it'd be nice to get this work "moving forward".
[20:20] <bollini> it is much more than dao here...
[20:20] <tdonohue> I still think mdiggory's suggestion for incremental improvements would make this easier to review. As it is, it's a bit large, and has very little docs/explanation with it.
[20:20] <bollini> it introduce hibernate
[20:21] <mhwood> Yes, he says "I need X" but not really why. Or I'm too dense to see why.
[20:22] <helix84> mhwood: he needs dao for SpringUI
[20:23] <mhwood> No, why does he need ContextService? Not clear at all.
[20:23] <helix84> also, how long have we been talking on pushing functionality down from interfaces into a business layer?
[20:24] <mhwood> Too long. Is that what this does?
[20:24] <helix84> i don't think so, but it rebuilds a lot of stuff. that's an opportunity to do what we wanted to do.
[20:24] <helix84> on the layer below UIs
[20:26] <tdonohue> yea, the problem here though is that we all don't understand *how* this is "rebuilding stuff", other than the few sentences of explanation around "adding hibernate" and moving around DB tables. It's still too dense to fully comprehend the extent of these changes. Which is why it might be nice to split up into understandable "chunks"
[20:26] <tdonohue> Or maybe I should say, I find it too dense. I like the conceptual ideas here. Just have a hard time understanding how to use it & what all it affects based on these changes (and what may break along the way and need fixing)
[20:26] <mhwood> Like the annual US Federal budget that (these days) gets debated for 14 months and then shot down.
[20:27] <helix84> i'll make sure to send him the link to today's log
[20:27] <bollini> my opinion here is... we need a big refactoring to introduce DAO, ORM, ApplicationService pattern, etc. but this is a very big change and a disruptive one
[20:27] <bollini> the change all in one is to big to review... but it is not splittable in more chunks
[20:28] <PeterDietz> There is merit to bringing it all in one-big-pull-request, otherwise, you have to take each chunk, and get them approved semi-quickly
[20:28] <bollini> if you split it in chunks you need to give up some expectation and this make the work less interesting
[20:29] <tdonohue> the detriment is though that an "all in one-big-pull-request" can sit around forever (now going on 5 months) while waiting for review
[20:29] <bollini> i.e. to split the work... we should introduce DAO separatly from Hibernate... but this could make the hibernate integration more difficult or less efficient than expected
[20:29] <hpottinger> not necessarily "we neeed more PRs", just explain all the bits, correct?
[20:29] <tdonohue> maybe the "balance" here is to have more explanation of changes.
[20:29] <helix84> (I don't think the delay is just due to lack of review, we're all juggling many plates)
[20:30] <tdonohue> hpottinger: correct. One big PR + not much explanation = it's gonna sit around for a while until we understand it
[20:30] <bollini> we should be honest... this is a so big change that most of us should be involved actively. These changes alone are worth a major release
[20:31] <hpottinger> bollini++
[20:32] <tdonohue> bollini ++ as well
[20:32] <bram-atmire> agreed
[20:32] <mhwood> So we need more insight into what's being done, so that we *can* be effectively involved.
[20:32] <helix84> so, the consensus seems to be we'll just request more explanation of changes?
[20:32] <PeterDietz> Ok, so I would say, I would prefer to use Hibernate over postgres. To get there, you need to add DAO. To get this to work, you need to modify Context / Service
[20:32] <bram-atmire> would it be useful to try to run his new core? https://github.com/lyncode/DSpace/tree/new-core
[20:32] <kompewter> [ lyncode/DSpace at new-core · GitHub ] - https://github.com/lyncode/DSpace/tree/new-core
[20:32] <bram-atmire> and try to break things as a way of testing?
[20:33] <helix84> new-core is the branch the PR we're discussing was made from
[20:34] <PeterDietz> You could have an omnibus vote, do you want ALL of that, and then, here's a big PR that implements ONLY-ALL of that
[20:35] <tdonohue> Sounds like the best we can do here is ask for more info: Explanation of the changes in a bit more detail. How do we need to help out (i.e. what is missing / what may break) if we were to schedule this for 4.0?
[20:36] <tdonohue> With that info, I *hope* we could make a decision around whether DAO is something we'd want to tackle for 4.0 together/jointly. Or if we need to rethink this more
[20:36] <hpottinger> and, if we do schedule for 4.0, what about the idea of *just this* for 4.0?
[20:36] <helix84> I talked to Joao two days ago and he said he'll be able to resume this work around August - which may be too late for 4.0
[20:37] <tdonohue> yea, that may be too late for 4.0
[20:37] <helix84> so you may want to consider whether you'll be able to help with it
[20:37] <helix84> or perhaps request a smaller change for 4.0
[20:37] <tdonohue> this is such a massive change, we likely need to get it moving forward soon.
[20:38] <mhwood> I should think that ContextService is a fairly small piece that could be done anytime. But I still want to understand why we need it.
[20:39] <tdonohue> It seems reasonable that we could potentially to "dspace-services into dspace-api" merge and ContextService for 4.0 (as preparatory steps). But, as mhwood says, we may need to better understand why we need it
[20:39] <bollini> just to note that all the content classes are still here org.dspace.content.*
[20:39] <tdonohue> OK. wondering if we should move on for today. We've spent 40mins now on DAO... feel like this discussion is slowing down.
[20:40] <bollini> this mean that to use the new structure (DAO/Hibernate/etc) we need to rebuild all the UIs on the new API
[20:41] <bollini> the only thing that I'm sure is that I don't want to have two really different layer that work concurrently on the same db (databasemanager stuff and hibernate)
[20:42] <tdonohue> bollini: yea, I don't think any of us want to do any of that (especially not before 4.0). This is part of the reason why I think I need more info here. Not sure what all would "break" from these changes.
[20:42] <helix84> bollini: is it possible that the APIs will remain the same here? (like your Solr implementation of BrowseDAO)
[20:42] <helix84> s/APIs/interfaces/
[20:42] <kompewter> helix84 meant to say: bollini: is it possible that the interfaces will remain the same here? (like your Solr implementation of BrowseDAO)
[20:43] <mhwood> If the UIs know about the storage layer then we need to fix that regardless of how we organize the storage layer.
[20:43] <tdonohue> mhwood ++
[20:45] <tdonohue> Wondering if we should use any of remanding time in this meeting to touch back on the REST API discussion (in #dspace earlier) or the "Private items" questions (also in #dspace earlier)?
[20:46] <bollini> if we are able to get some agreement about the private items we will be able to finalize two pull requests
[20:47] <hpottinger> if anyone here is thinking "hey, what's this about REST-API? you can go here: https://groups.google.com/forum/#!topic/dspace-rest/AAHvkJxw9sg
[20:47] <kompewter> [ Google Groups ] - https://groups.google.com/forum/#!topic/dspace-rest/AAHvkJxw9sg
[20:48] <mhwood> My only concern about private items is that it's papering over the cracks in our access control model, but we can do that now and remold access control later.
[20:49] <PeterDietz> That google-group is just a sounding board for the self-formed DSpace REST group that is the OR13 panel.
[20:49] <PeterDietz> err, i mean, everyone is free to join in. I would love to have plenty of discussion, it was conceived to facilitate communication
[20:50] <hpottinger> PeterDietz++ more the merrier
[20:51] <helix84> PeterDietz: I know you meant the new discussion group as a way not to clutter up the regular mailing lists. But let me suggest that so many people are interested in REST API that it would be a good idea to use the regular mailing lists.
[20:52] <PeterDietz> People on the mailing lists give me hell for pasting in images / uploading files, so I like the idea of this group
[20:52] <PeterDietz> maybe the -devel group is friendlier
[20:52] <hpottinger> -developers are always friendlier :-)
[20:52] <bollini> to finalize on the private item issues... what do you think if I send a proposal of what we mean for withdrawn items and private items to the devel list? can we vote on these incoming definitions and change the code to reflect them?
[20:52] <tdonohue> I can understand the need for an organized "discussion group" for REST API. But, I do think it needs to be better advertised & communicated out.. As it is, not sure most folks have any understanding of what is going on around REST
[20:53] <helix84> PeterDietz: which ML do you mean? I was actually suggesting -devel.
[20:53] <bram-atmire> bollini++
[20:54] <tdonohue> bollini++ seems reasonable. For me, "private items" = "access restricted items" (may be a limited access restriction, like embargo). "withdrawn items" = "removed from the archive".
[20:54] <mhwood> ??? But withdrawn items are still in the archive; you just can't get at them.
[20:54] <mhwood> bollini++
[20:54] <helix84> bollini: I like the proposal, although I would expect @mire to draft it, since they came up with the concept
[20:54] <PeterDietz> dspace-tech is the one I usually get private replies saying I have a really slow internet connection, and your giant binary file brought my entire country's internet to its knees for 3 days
[20:55] <mhwood> PeterDietz: so use pastebin on -tech. But discussion is tiny compared to most binaries.
[20:55] <tdonohue> mhwood: "in_archive" are stuff actually in the archive. Withdrawn are moved to another "state" (like "workflow_items" and "workspace_items")... so, to me "withdrawn" is an *item state*. "private" is just access restrictions/embargo
[20:55] <bram-atmire> I don't necessarily agree helix, we're not doing active development on this right now
[20:56] <bram-atmire> might also be related to this JIRA: https://jira.duraspace.org/browse/DS-658
[20:56] <kompewter> [ [#DS-658] Provide a "nonAnon" attribute to XMLUI theme - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-658
[20:56] <kompewter> [ https://jira.duraspace.org/browse/DS-658 ] - [#DS-658] Provide a "nonAnon" attribute to XMLUI theme - DuraSpace JIRA
[20:58] <bollini> helix84: bram-atmire: I will try to draft something (just few lines), we can work all together to improve it before vote
[20:58] <bram-atmire> sure
[20:59] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:00] <tdonohue> So, about REST API. I'm curious..has work begun on it? It seems like the discussions on that list are very few/far between. Just wondering how others can help
[21:01] <bollini> sorry, today I need to leave exactly to the clock time. Thanks to all for the discussion
[21:01] <PeterDietz> re:REST. So, everyone has different schedules, and levels of commitment, and we don't work in the same buildings. Its mostly just me I'd say
[21:01] <bram-atmire> also got to go, good meeting
[21:01] * bollini (~chatzilla@host11-63-dynamic.245-95-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130409194949])
[21:01] * bram-atmire dspace-high-five for everyone
[21:02] * bram-atmire (~bram@94-225-35-170.access.telenet.be) Quit (Quit: a pull request a day keeps the doctor away)
[21:02] <PeterDietz> I spent a few weeks fishing for recommendations
[21:02] <PeterDietz> Then a few weeks trying out the recommendations
[21:02] <PeterDietz> Now, I've done a week of implementing something in JERSEY
[21:03] <mhwood> Sorry, I have to go too. Thanks all.
[21:03] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:03] <PeterDietz> I'm gonna need to head out shortly
[21:03] <helix84> PeterDietz: where were you fishing? I missed the hook.
[21:03] <tdonohue> Ok. Good to know PeterDietz. Thanks for your hard work.
[21:03] <PeterDietz> Maybe I didn't ask you
[21:03] <tdonohue> I'm also curious if you asked around on dspace-devel. Just wonder if other suggestions would pop up along the way?
[21:03] <PeterDietz> I didn't cast an infinitely wide net. I only have a Fishing License in Ohio
[21:03] <helix84> it's not about me personally, but there are many stakeholders in the public
[21:04] <hpottinger> I think one of the nicest things about PeterDietz's work is that it gives us a non-sakai REST-api to tinker with, which is where the discussions of the other REST-APIs tend to fall down
[21:04] <tdonohue> +1 to that. I like the idea of using something that is more "standard/supported" in the Java world
[21:05] <hpottinger> helix84, the thing is that the discussion started as a way to build something that uses the existing REST-APIs, which collided quickly with dissatisfaction with those APIs
[21:07] <helix84> that's great - getting actual feedback - but why wasn't this posted or at least summed up publicly so that we can get even _more_ feedback?
[21:08] <hpottinger> busy days, busy busy days
[21:10] <helix84> don't take me wrong, i want a REST API as much as you do, but doing things in private was the very same mistake the two previous implementations made
[21:11] <PeterDietz> I'll send discussions to dspace-devel from now on. I remember getting crickets when I posted about the REST-API client app
[21:11] <hpottinger> I think it would be helpful to think of this as more of an experiment, and less of an actual project
[21:12] * l_a_p (~chatzilla@93-57-61-229.ip163.fastwebnet.it) has left #duraspace
[21:12] <hpottinger> might turn into something, might not, lots of feedback might not be appropriate right now
[21:12] <PeterDietz> Yeah, the goal was just to make it so we can get to PEI without being empty handed
[21:13] <PeterDietz> I have a new thesis: If we want to go fast, go alone. If you want to go far, go alone.
[21:13] <tdonohue> for what it's worth, it looks like Fedora 4 is using JAX-RS for their new REST API. Currently with Apache CXF under it..though I found instructions to swap over to using Jersey: https://wiki.duraspace.org/display/FF/Switching+Jax-RS+implementation+from+CXF+to+Jersey
[21:13] <kompewter> [ Switching Jax-RS implementation from CXF to Jersey - Fedora Futures - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FF/Switching+Jax-RS+implementation+from+CXF+to+Jersey
[21:13] <hpottinger> but, like everything posted on GitHub, it's ready for anyone to fork, tinker with, etc.
[21:14] <hpottinger> https://github.com/peterdietz/dspace-rest.git
[21:14] <kompewter> [ peterdietz/dspace-rest · GitHub ] - https://github.com/peterdietz/dspace-rest.git
[21:14] <PeterDietz> jersey isn't my preferred technology, but its the most standard "reference implementation", that its better to just use that
[21:15] <tdonohue> PeterDietz: the downside is.. the more you "go alone" the more you have to "maintain alone" :) But, I understand the need for small teams to go get stuff done quickly on their own. It's just good to loop back in the "bigger community" on the work every once in a while for feedback
[21:15] <tdonohue> PeterDietz : yea, to be clear, I wasn't disrespecting your choice of Jersey. Just wanted to make it known what Fedora 4 is using, in case it's of interest to anyone :)
[21:16] <tdonohue> Jersey seems fine though.. I know it's widely used
[21:16] <hpottinger> anybody who wants to play with this code, it's on GitHub, and know that you'll be welcomed, especially if you come ready to code :-)
[21:17] <PeterDietz> We're still figuring out use-cases, and needing that to be written. "As a __________, I want _________, so that _____________"
[21:18] <PeterDietz> Tricky things that I want are scopes. /communites/123/collections, so you get the subset of collections, only within comm:123
[21:18] <PeterDietz> I also wanted to experiement with using Google Groups. I don't like sourceforge mailing list archive
[21:18] <tdonohue> Use cases are probably something that folks on main DSpace lists would be glad to help with...as long as we get that basic "template" posted to the Wiki that folks can use to add their own use cases.
[21:19] <helix84> PeterDietz: I'm wondering if you though about or heard any feedback on using Solr (search core) as part of the API and only implementing the rest (no pun intended) of it
[21:19] <tdonohue> SourceForge mailing lists are a constant pain, I agree. The only reasons we've stuck with them is that (1) It's hard to migrate them to Google Groups, and (2) Once you are in Google Groups, you are currently stuck. There is no way to migrate a Google Group elsewhere.
[21:20] <hpottinger> Google Groups are a bit laggy, too, on the e-mail side
[21:21] <PeterDietz> So, breadth-first vs depth-first.. I want to get all resources as an endpoint. /communities /collections /items /bitstreams, and to just spit out their basics
[21:22] <PeterDietz> You mean use the discovery-core of SOLR as the datastore, I suppose we could get there
[21:22] <PeterDietz> I would like the API to be fast.. Just a moment ago I ran AB at it, and it died after 100 new Context() calls, since I wasn't re-using
[21:24] <PeterDietz> ...but maybe put up DAO as a first class citizen of DSpace. Where write's use hibernate, and fire re-index operations on the SOLR index. Then reads, can all be under-the-scenes performed by the faster index
[21:24] <helix84> PeterDietz: correct, Solr already makes accessible a huge part of the API and many people may already be familiar with it because it's widely used
[21:24] * tdonohue has gotta head out in a bit. Obviously we're well into "overtime" here & just in the post-discussion period of the meeting.
[21:25] <PeterDietz> I'll move the REST discussion to dspace-devel. I've gotta head out.. And go grocery shopping with the fam
[21:25] <tdonohue> sounds great. Thanks for all the research you've started, PeterDietz
[21:26] * PeterDie_ (~peterdiet@dhcp-164-107-110-134.osuwireless.ohio-state.edu) has joined #duraspace
[21:30] * PeterDietz (~peterdiet@128.146.173.70) Quit (Ping timeout: 252 seconds)
[21:31] * PeterDie_ (~peterdiet@dhcp-164-107-110-134.osuwireless.ohio-state.edu) Quit (Ping timeout: 264 seconds)
[21:35] * hpottinger (~hpottinge@mu-161251.dhcp.missouri.edu) Quit (Quit: Leaving)
[21:51] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:30] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.