Timestamps are in GMT/BST.
[6:38] -hubbard.freenode.net- *** Looking up your hostname...
[6:38] -hubbard.freenode.net- *** Checking Ident
[6:38] -hubbard.freenode.net- *** Found your hostname
[6:38] -hubbard.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:13] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:27] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[16:06] -RichiH- [Global Notice] Hi all. We just blogged about SOPA/PIPA on http://blog.freenode.net/2012/01/on-sopapipa/ and suggest you join ##sopa if you are interested in these proposed bills or other discussion around this general topic. As always, have a nice day and thanks for flying freenode air!
[19:39] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[19:58] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) has joined #duraspace
[19:58] <KevinVdV> Hi everybody
[19:59] <PeterDietz> Hi KevinVdV + everybody
[19:59] <mhwood> (ObCheersRef) [everybody] KevinVdV!
[19:59] * PeterDietz-alt (~dspace@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:00] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:01] <PeterDietz> let me test that kompewter is alive...
[20:01] <PeterDietz> .wiki DSpace
[20:01] <PeterDietz> hmm, thats odd
[20:01] <PeterDietz> .wik DSpace
[20:01] <kompewter> "DSpace is an open source software package that provides the tools for management of digital assets, and is commonly used as the basis for an institutional repository." - http://en.wikipedia.org/wiki/DSpace
[20:01] <PeterDietz> ahh, wrong syntax ;)
[20:05] <tdonohue> hi all...lost track of time here, sorry
[20:05] <tdonohue> here's the agenda for today's meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-01-18
[20:05] <kompewter> [ DevMtg 2012-01-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-01-18
[20:06] <tdonohue> might as well kick off our normal JIRA Review process. https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-924+ORDER+BY+key+ASC
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-924 ] - [#DS-924] ItemImport should allow you to import to a workspace - DuraSpace JIRA
[20:06] <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-924+ORDER+BY+key+ASC
[20:06] <tdonohue> starting with DS-924
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-924 ] - [#DS-924] ItemImport should allow you to import to a workspace - DuraSpace JIRA
[20:06] <PeterDietz> 924 -- looks like we need to bug Graham to see the code
[20:07] <tdonohue> aha, yes, correct. Tim will add a brief comment (after meeting) to pester Graham for the code
[20:07] <tdonohue> next up, DS-925
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-925 ] - [#DS-925] ItemImport does not delete items that weren't placed into the archive - DuraSpace JIRA
[20:08] <mhwood> Looks related to 924
[20:08] <PeterDietz> this is the case where your batch of imports went to a collection with some type of workflow?
[20:09] <tdonohue> yep, needs to be linked back to DS-924, as these are connected
[20:09] <kompewter> [ https://jira.duraspace.org/browse/DS-924 ] - [#DS-924] ItemImport should allow you to import to a workspace - DuraSpace JIRA
[20:09] <aschweer> might be worth asking Graham if he has a patch for this by now
[20:10] <tdonohue> ok, Tim can pester Graham on this one too. We'll just move along for now
[20:10] <PeterDietz> what would "correct" behavior do.. report accurately as to what happened, or pop these in-progress submissions out of the workflow, and delete them?
[20:11] <PeterDietz> I use ItemImport loads... I'm guessing the in-progress / workflowed things need to be removed/deleted
[20:11] <aschweer> to be honest, I think 924 is related to some of the non-standard things that Symplectic do with DSpace
[20:12] <tdonohue> so, does anyone else see a use case for Ds-924 / Ds-925, or do we question the need for these altogether?
[20:13] <tdonohue> (honest question -- I personally have never needed to do either of these operations with batch import)
[20:13] <aschweer> I meant 925 re Symplectic (not quite awake yet). I can see a use for 924, and 925 probably could do with some elaborating
[20:13] <PeterDietz> -w,--workflow send submission through collection's workflow
[20:14] <PeterDietz> https://github.com/peterdietz/SAFBuilder/wiki/Basic-DSpace-Import-Process
[20:14] <kompewter> [ Basic DSpace Import Process - GitHub ] - https://github.com/peterdietz/SAFBuilder/wiki/Basic-DSpace-Import-Process
[20:14] <mhwood> 925 should be addressed, whether it is made to complete the action properly or fail it properly.
[20:14] <aschweer> I think he means to a specific workspace -- ie, make a specific user take the task
[20:14] <PeterDietz> I never import into the workflow, our batch-ingest materials are always ready-to-go-live
[20:15] <PeterDietz> so.. if one uses the -w option, then I'm guessing that these should just work.. I'd assign both to Graham, he's probably the most interested in them working anyways
[20:15] <tdonohue> ok, well, it sounds like we better just follow up with Graham in both cases. Both Ds-924 and Ds-925 need code (if available) and maybe more explanation around use cases
[20:16] <tdonohue> PeterDietz -- no, Ds-924 is related to *workspace* which is different than *workflow*. "Workspace" is an item that hasn't yet been finished/submitted yet, if you recall
[20:16] <aschweer> oh my bad too then
[20:17] <tdonohue> Recall, Item lifecycle goes: "Workspace Item" (not finished) -> "Workflow Item" (finished & in workflow) -> Archived Item
[20:17] <aschweer> but assign both to Graham sounds like the best choice to me
[20:17] <tdonohue> ok, Ds-924 and Ds-925: Followup with Graham on both (Tim will add a comment to each)
[20:18] <tdonohue> next up, DS-927
[20:18] <kompewter> [ https://jira.duraspace.org/browse/DS-927 ] - [#DS-927] REST-API All item submitter information is returned for an item request, even for an anonymous request. - DuraSpace JIRA
[20:19] <PeterDietz> I like mhwood's rant on this one
[20:19] <aschweer> me too
[20:20] <tdonohue> +1 to mhwood's comments. Though, that may be a larger project, would it not?
[20:20] <mhwood> Definitely a larger project.
[20:21] <PeterDietz> When I was working on WebMVC UI, I ran into that same issue.. this code should be clear enough: https://github.com/DSpace/webmvc/blob/master/webmvc-api/src/main/java/org/dspace/webmvc/controller/admin/ItemController.java#L93
[20:21] <kompewter> [ webmvc-api/src/main/java/org/dspace/webmvc/controller/admin/ItemController.java at master from DSpace/webmvc - GitHub ] - https://github.com/DSpace/webmvc/blob/master/webmvc-api/src/main/java/org/dspace/webmvc/controller/admin/ItemController.java#L93
[20:21] <mhwood> What about the suggestion to just return a user identifier, and then some other bit of code can decide whether the client has access to details of that?
[20:22] <aschweer> mhwood +1
[20:22] <tdonohue> I'd be fine with the approach to just return user identifier
[20:22] <PeterDietz> same here
[20:23] <tdonohue> someone want to add a comment to that effect to this issue? sounds like we are in agreement
[20:23] <mhwood> Well, the suggestion is already there....
[20:23] <tdonohue> right -- but a comment to say that we discussed this and that we all came to the conclusion that that suggestion is probably the best solution for now
[20:23] <PeterDietz> Kinda wish Mark Diggory were around.. I need to bug him about "business services".. i.e. some of the middle code that handles these once-and-for all problems
[20:24] <PeterDietz> I don't mind adding a comment to this 927 issue
[20:24] <KevinVdV> MDiggory is unable to attend today I'm afraid he has other obligations (I checked)
[20:24] <tdonohue> PeterDietz -- go ahead and add a comment to the issue. thanks!
[20:25] <tdonohue> ok. we'll stop there for today with JIRA review.
[20:25] <tdonohue> The only other big topic I had for today was to start brainstorming out some things we may want to see happen in 3.0 (and potentially even get together some volunteers if we can find them).
[20:26] <tdonohue> Though, if we wanted, we also could chat about the "Business Services" idea (even if mdiggory cannot join us today). Or we can shelve that for a later date
[20:27] * PeterDietz inserts subliminal message that all should learn some basics about Git.. the demo site is up at: https://github.com/DSpace/demo.dspace.org
[20:27] <tdonohue> (As I see "business services", i.e. shared logic across UIs, as a general concept that might be worth moving towards in 3.0, as much as we can do so)
[20:27] * tdonohue seconds that subliminal message. ;)
[20:27] <aschweer> funny, I was just thinking how parts of the jira review could happen in pull requests on github :)
[20:28] <tdonohue> +1 aschweer. That has come to my mind as well -- that during a pull request, we essentially are doing basic "code reviews" or similar
[20:28] <PeterDietz> that would be wild to have this much rapid feedback on one issue, all at once
[20:29] <PeterDietz> tdonohue: How much reused code do you have in the replication suite?
[20:29] <mhwood> Well, information visibility is certainly a cross-cutting concern. DSpace does not organize it very well IMHO.
[20:29] <aschweer> making heavy use of pull requests could be a big part of the answer to the question of how we'd coordinate our work with github
[20:30] * tdonohue notices two conversations going on at once here :) Do we want to talk github, or do we want to talk Business Services?
[20:30] <aschweer> I'm happy to stop talking github -- just wanted to put in this link for people who haven't got around to looking at github yet: http://help.github.com/send-pull-requests/
[20:30] <kompewter> [ Help.GitHub - Send pull requests ] - http://help.github.com/send-pull-requests/
[20:31] <tdonohue> I move to discuss Business Services and loop back to github as needed (since we did talk github last week a bit, and have an upcoming mtg on Feb 29 to discuss possibly migrating to github)
[20:31] <tdonohue> thanks aschweer
[20:32] <tdonohue> Ok, RE: business services + Replication Suite. The Replication Suite doesn't really "reuse" any code at all, PeterDietz. Though, it does wrap calls to some of the Packager/Crosswalks.
[20:33] <tdonohue> In a way, the Replication Suite is a "re-envisioning" of how Packagers likely should have been built. In a future stage, the Packagers/Crosswalks may end up "swallowed up" / refactored into that suite of tools
[20:33] <tdonohue> (that's just conjecture right now -- no immediate plans to do so)
[20:34] <tdonohue> but, this doesn't have so much to do with Business Services per say.
[20:34] <PeterDietz> gotcha, I was just wondering if you had noticed the code re-use problem in that (or other projects your working on)
[20:35] <tdonohue> at this point, I've mostly noticed the code reuse issues when it comes to the UIs (XMLUI, JSPUI, LNI, OAI, SWORD)
[20:35] <tdonohue> as there's a lot of hardcoded logic in each of the UIs, which really should/could be shared
[20:35] <tdonohue> (as we all know)
[20:35] <PeterDietz> ...which also hits when you do something like REST, webmvc, <insert-new-UI>
[20:36] <tdonohue> yep.
[20:37] <mhwood> So we need to list the common concerns, so we know what to start factoring out.
[20:37] <tdonohue> One concept we could start to think about is whether we could be making more use of REST as that "shared logic". I.e. if most UIs primarily interacted via REST API, then they could share logic there. However, that's obviously a large refactoring.
[20:38] <tdonohue> (sorry, jumped the gun a bit...mhwood is likely got the right approach here)
[20:39] <PeterDietz> I was just writing some solr queries in XMLUI, and since some queries are really slow.. I was thinking it would be nice to have XMLUI draw the page, and insert (do-ajax-request-here-to-API), then get progress spinners while it waits..
[20:39] <mhwood> I worry about having code all over the place (or even just in REST) that needs to understand internals of DSpace objects.
[20:40] <tdonohue> mhwood -- agreed. Just looking at steps to move the code downward. Ideally, if the code has nothing to do with organizing content for UI display, it *shouldn't* be at the UI level (rather it should be in a lower-level API)
[20:40] <PeterDietz> ...and for other developers getting started with DSpace, since there's no business methods around, the developer has to understand the internals of DSpace, before they get acclimated enough to use it.. i.e. high barrier
[20:41] <tdonohue> this would include code like "logic to determine access rights" and similar
[20:41] <tdonohue> PeterDietz -- yep, agreed
[20:42] <mhwood> We have infrastructure for access rights, but each UI decides what the rights mean. Ugh.
[20:43] <PeterDietz> One of the OAI crosswalks (METS) I think exposes provenance... So, since the access is determined by each UI, you have to plug the leaks at each UI
[20:43] <tdonohue> I think the overarching problem here is that we really don't have a full "API" for dspace. Sure, there's 'dspace-api', but in some areas its more related to infrastructure. There is no single API that people can write UIs (or similar against) -- they are stuck having to actually look at an existing UI to write a new UI
[20:44] <mhwood> Exactly. Instead, there should be something central that decides whether the access token held by this session permits access to provenance.
[20:44] <mhwood> Item seems like a good place to put that logic.
[20:45] <mhwood> So what services does a UI need in order to fill its output with specific content?
[20:46] <mhwood> And to implement UI operations?
[20:49] <tdonohue> I think a UI needs the standard CRUD services (create/read/update/delete). But, READ would include things like Search/Browse, and would also need to respect access rights.
[20:50] <tdonohue> currently, I think the Access rights area and the Search/Browse that seem the most repetitive across UIs (at least from what I've seen)
[20:50] <mhwood> IIRC there are sites that want to be able to say: "yes we have that; no you can't see it". So READ and SEARCH are two different requests.
[20:50] <mhwood> Embargo comes to mind.
[20:50] <tdonohue> true
[20:52] <tdonohue> I was lumping that all into an "access rights layer" which decides how to respond to your request (it may actually claim it "doesn't exist" if it's under embargo, or it may say "it does exist, but it's embargoed", based entirely on your access rights)
[20:54] <tdonohue> again, I start to circle back to the idea of a true "REST API". A true REST API should handle all this stuff for you, thus letting you not need to worry about it at the UI level. Though, it's arguable which logic should actually be written into the REST API, and which should sit on the "layer" just below that REST interface.
[20:54] <PeterDietz> One question I have, is where to put this "common" business code. Right in "Item" was suggested, I wonder if it will be so clear
[20:54] <mhwood> I have a nagging feeling that a single "access rights layer" would have to know a lot about various objects. Maybe that goes away when "metadata for all" comes in.
[20:55] <PeterDietz> ..so clear for all objects that you try to do stuff to. Submission is quite complex it has a dspace-api section, and each UI implements their own things from there
[20:55] <aschweer> from what I've seen in other frameworks, they'd use an Item (mainly a dumb data object) and an ItemController or ItemServiceProvider (or whatever) for "doing things with Items"
[20:57] <tdonohue> PeterDietz -- I'd venture to guess that there's no single answer. Some "common" logic may be something that is easily moved down to Item itself. Other logic may not "fit" there, especially if it's more "doing things with Items" (like aschweer says)
[20:58] <aschweer> tdonohue +1 I also think it's a case-by-case thing
[20:58] <mhwood> What sort of things would we do to an object that the object shouldn't need to understand?
[20:59] <PeterDietz> ?? maybe what UsageEvents to fire afterwards? but we have that part worked out pretty well
[21:00] <mhwood> Come to think of it, we might find that there isn't any real difference between Item, Collection, etc. w.r.t. cross-cutting concerns, and so the logic can be pushed all the way down to DSpaceObject.
[21:00] <PeterDietz> abstract DSO, Item might implement delete differently than Collection
[21:01] <mhwood> Ask each child DSO (if any) to unlink itself from me, then unlink myself.
[21:02] <tdonohue> both are interesting ideas. I think the concept here is to separate the Objects from the activities across Objects (e.g. Search/Browse/Filter/Sort/Batch Ingest/Batch Export and similar)
[21:02] <mhwood> Bitstream has 0 child DSOs but can still unlink all 0 of them.
[21:04] <tdonohue> I like the direction you are thinking mhwood. Technically maybe everything really should just be a DSO, and "type" (Bitstream, Item, Collection) is a property on that DSO.
[21:04] <tdonohue> though, that's a huge refactoring project :)
[21:05] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[21:06] * tdonohue notices we are already over time. But, this is an interesting discussion. If folks need to head out feel free.
[21:06] <mhwood> mdiggory had some interesting comments on how the type system ought to work, but time ran out and the topic hasn't come up again, and I didn't yet quite grasp where he was going....
[21:06] <tdonohue> sounds like maybe we need to try and schedule a "Special Topic Meeting" on the idea of Common Business Logic
[21:07] <tdonohue> (or generally, "refactoring towards Common Business Logic")
[21:07] <mhwood> Hmmm. Site, Community, Collection, Item, Bundle, Bitstream are all DSOs now, yes? Some of the weirdness is that DSO types have properties which ought to be in the metadata table instead, I think.
[21:08] <aschweer> metadata for everthing would be a step towards fixing that, wouldn't it?
[21:08] <mhwood> Yes, I think so.
[21:09] <tdonohue> yes, mhwood, those are all DSOs. But, Metadata is not a DSO. Neither is WorkSpaceItem nor WorkflowItem (oddly enough)
[21:09] <mhwood> It's an opportunity to revisit what is a property (in the OO sense) and what is a metadata field.
[21:10] <mhwood> tdonohue: ah, yes. I have some (re)reading to do....
[21:12] <tdonohue> yea, essentially I agree though. It'd be nice to revisit DSOs and look closer at what is/is not a DSO and rethink/refactor as needed. I do agree it'd be a good step towards the Metadata for Everything idea. (since all DSOs should likely have Metadata, but currently they do not)
[21:15] <mhwood> So, for example, MetadataField (or whatever) needs to be a DSO so it can participate in access control using the existing infrastructure. Then the access controller could have a method that takes an array or list of fields plus a session's access token, and returns a collection of fields that may be presented to the user.
[21:16] <tdonohue> +1
[21:16] <tdonohue> technically, in my mind, anything that stores "content" should likely be a DSO. Whether that content is a content file, metadata, etc.
[21:17] <mhwood> Yes, we should be free to change the storage layer for a piece of information without changing its access control.
[21:18] <tdonohue> exactly
[21:18] <aschweer> which to me almost suggests we might not want a monolithic DSO, but instead "favour composition over inheritance" -- interfaces like HasMetadata, Storable, AccessControlled
[21:20] <aschweer> then any "thing" can be composed of whatever combination of the interfaces, and to avoid code duplication have eg a delegate to a basic implementation of each of the applicable interfaces
[21:20] <mhwood> Can we leverage the Java type system somehow so that we don't have to create another one?
[21:20] <aschweer> I don't know enough about Annotations to tell whether they might be helpful for this
[21:20] <tdonohue> aschweer -- yea, I'd agree with that concept.
[21:21] <tdonohue> RichardRodgers has taken to using Java Annotations more heavily in how he has setup the ReplicationTaskSuite. I've started to follow suit there
[21:21] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[21:21] <tdonohue> so, that codebase may be something to look at as an example for how Annotations could be used
[21:22] <aschweer> they're used in the curation system as well
[21:22] <tdonohue> actually -- those Annotations are in the CurationTaskSystem itself. my mistake :)
[21:23] <tdonohue> yep, org.dspace.curate.* has defined several Annotations: Distributive, Mutative, Suspendable, etc. which help to define what a specific "task" does and can support
[21:23] <aschweer> hibernate uses annotations quite heavily, afaik
[21:24] <aschweer> I just found this http://www.mkyong.com/spring/maven-spring-hibernate-annotation-mysql-example/ and it looks very interesting
[21:24] <kompewter> [ Maven + (Spring + Hibernate) Annotation + MySql Example ] - http://www.mkyong.com/spring/maven-spring-hibernate-annotation-mysql-example/
[21:24] <aschweer> (but need to run off now -- bye all!)
[21:24] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:31] <KevinVdV> Need to go, cya all
[21:31] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[21:31] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) Quit (Quit: KevinVdV)
[21:42] * blah (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[21:47] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[21:57] * blah (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[22:04] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[22:07] <mhwood> Bye all.
[22:07] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:20] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[23:01] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:10] * sandsfish (~sandsfish@18.111.61.247) has joined #duraspace
[23:11] <sandsfish> hey guys. anyone here know if there's a way in the XMLUI Wing element Xref to add a property to have the link open in a new window?
[23:14] * sandsfish (~sandsfish@18.111.61.247) Quit (Client Quit)
[23:23] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[23:40] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[23:53] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.