Timestamps are in GMT/BST.
[6:49] -verne.freenode.net- *** Looking up your hostname...
[6:49] -verne.freenode.net- *** Checking Ident
[6:49] -verne.freenode.net- *** Found your hostname
[6:49] -verne.freenode.net- *** No Ident response
[6:49] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:49] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:49] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:15] * stevew (~stevew@2001:630:11:f20f:dcac:8b3a:2717:3a1f) has joined #duraspace
[8:42] * stevew (~stevew@2001:630:11:f20f:dcac:8b3a:2717:3a1f) Quit (Ping timeout: 245 seconds)
[12:01] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[13:01] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:55] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[14:41] * PeterDie_ (~peterdiet@128.146.173.59) Quit (Remote host closed the connection)
[15:06] * Vijeenroshpw (75c98e74@gateway/web/freenode/ip.117.201.142.116) has joined #duraspace
[15:06] <Vijeenroshpw> hello
[15:06] <Vijeenroshpw> good evening
[15:06] * PeterDietz (~peterdiet@128.146.173.59) has joined #duraspace
[15:55] <Vijeenroshpw> Is it possible to Emulate GitHub like functionality using DURASPACE ?
[16:02] <Vijeenroshpw> hello , any body home ?
[16:43] <tdonohue> Vijeenroshpw: DuraSpace is an organization, and not a software platform. The software platforms that DuraSpace helps to support are DSpace (http://www.dspace.org), Fedora (http://www.fedora-commons.org) and DuraCloud (http://www.duracloud.org)
[16:45] <tdonohue> Also, none of these software platforms are code repositories, like Git/GitHub or SVN. So, I'm not exactly sure what you are wanting to emulate about GitHub?
[18:00] * Vijeenroshpw (75c98e74@gateway/web/freenode/ip.117.201.142.116) Quit (Quit: Page closed)
[19:24] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:35] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:59] <tdonohue> Hi all, as usual our DSpace Devel mtg will be starting here shortly. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-22
[19:59] <kompewter> [ DevMtg 2012-02-22 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-22
[20:00] * cbeer (cbeer@2600:3c03::f03c:91ff:fedf:a498) has left #duraspace
[20:01] <tdonohue> Welcome all. We'll kick things off with a JIRA review as normal. https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-951+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-951 ] - [#DS-951] Monthly stats report ignores items archived on first and last day of the month - 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-951+ORDER+BY+key+ASC
[20:01] <tdonohue> today we begin at DS-951
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-951 ] - [#DS-951] Monthly stats report ignores items archived on first and last day of the month - DuraSpace JIRA
[20:01] <mhwood> Assigned to Andrea Schweer
[20:02] <tdonohue> Looks like aschweer has claimed this one. We can always see if she needs feedback/help
[20:02] * richardrodgers (~richardro@18.111.47.178) has joined #duraspace
[20:02] <tdonohue> moving along then, to DS-954
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-954 ] - [#DS-954] Browse Pagination - DuraSpace JIRA
[20:04] <tdonohue> interesting, sounds like a bug. Any volunteers to investigate this one, and look at Dan's suggested solutions?
[20:06] <mhwood> Wow, it's quiet in here. I will look at it.
[20:07] <tdonohue> ok, thanks mhwood.
[20:07] <tdonohue> yes, agreed, very quiet :)
[20:07] <tdonohue> ok, Ds-954 summary: mhwood will investigate
[20:07] <tdonohue> next DS-955
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-955 ] - [#DS-955] Anonymize IP-Logging to comply to privacy laws - DuraSpace JIRA
[20:10] <mhwood> Does hashing a 32-bit keyspace really provide much protection?
[20:10] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:10] <richardrodgers> See the concern, not sure DSpace is the place to address it (e.g. still can have IP addrs in Apache logs, etc)
[20:10] <tdonohue> to me, this seems like a reasonable request. A part of me wonders though if there's two stages here: (1) hash it initially, (2) after a month (or so) aggregate the stats and just remove specific IPs (once aggregated, we don't really need to keep IP specifics)
[20:11] <mdiggory> We are logging IP in both the dspace logs and that the statistics engine. This is more specific to annonymizing those.
[20:12] <mdiggory> its important that a number of actions happen prior to anonymization
[20:12] <tdonohue> richardrodgers -- good point. I agree about the logs. Not sure we should need to anonymize at the log level. I'd be more interested in not storing IPs forever in the stats engine
[20:12] <mdiggory> Most important of which is GeoIP evaluation
[20:13] <tdonohue> right, but after GeoIP eval is done, why keep around the IP? Can't it just be anonymized to a general location at that point? (or aggregated after a month or so)
[20:14] <mdiggory> We've been discussing a solution for distributed statistics aggregation for Dryad, part of which we've proposeda n approach of producing statistics specifc logs that only contain the event data that needs to be placed into solr. This would also act as a backup datasource for DSpace solr based statistics and provide a source for other stats tools as well.
[20:14] <mdiggory> these loggs would be generated by the UsageEvent system
[20:14] <mdiggory> and update of solr would be a separate process.
[20:15] <mdiggory> this is not dissimilar to the current dspace.log stats processing loogic
[20:15] <mhwood> Note the reference to privacy laws. Recall that, just because something is sensible and useful doesn't mean it isn't unlawful.
[20:15] <mdiggory> and yes, at that point what was in the log would be anonymized
[20:17] <tdonohue> mdiggory: makes sense -- yea, I'd assume we'd want to anonymize after GeoIP (or any other initial necessary IP analysis tasks). Is the work you describe for Dryad actually going to be open sourced?
[20:17] <mdiggory> one generally wants to reduce risk of any sort of risk of legal action if one can avoid it
[20:18] <mdiggory> sorry I was attempting to rewrite that thought before sending it...
[20:18] <mdiggory> yes, most everything in Dryad is OS
[20:19] <hpottinger> going back to mhwood's question re: hashing a 32-bit keyspace, I think it's sufficient to clear the hurdle of privacy concerns, probably insufficient if you were talking security concerns, though since the specter of legality has been invoked, probably a lawyer would need to weigh in on that
[20:19] <mdiggory> the intent is to bring back projects from Dryad whenever it is possible.
[20:21] <tdonohue> hpottinger & mhwood, I guess then the question would be whether we should think of providing an option to hash it in the logs -- as it sounds like we have some general agreement that once it gets to Stats Engine, to should be anonymized after GeoIP (or similar)
[20:21] <mdiggory> tdonohue: do you guys have any vampires (err Lawyers) available who can answer such questions
[20:22] <mhwood> I'm thinking that we might want to immediately extract aggregated measures such as GeoIP results and just destroy the address altogether -- not log anything. If a site has a specific problem then it could (with advice of counsel) insert additional logging to address the specific problem. I think that might satisfy the law very well and not lose much if anything of value.
[20:22] <tdonohue> no. DuraSpace doesn't have that much money to work with :) We might be able to borrow lawyers from a major university that we have a good relationship with though
[20:22] <mdiggory> university of Transylvania?
[20:23] <mhwood> The one in Kentucky?
[20:24] <mdiggory> mhwood: thats an interesting idea too however, we do retain the ip to post process bots if they are ever added to the bot lists.
[20:25] <mdiggory> so we need to be able to produce a hashing strategy to support detecting and cleaning out bots
[20:25] <hpottinger> deriving lat/long from IP and then storing that for stats sounds fine... would impact efforts to measure "impact" based on IP address, not sure if that's our concern, making it configurable would be best, not every institution has these concerns
[20:25] <tdonohue> mhwood -- agreed, interesting idea. I question that we could get all the IP analysis (GeoIP / bot processing) done quickly enough to make it "seemless" though (i.e. we may need to keep that IP temporarily as mdiggory is saying)
[20:26] <mdiggory> I"m not sure you got that... the identification of a bot may come long after the logging event itself
[20:26] <mdiggory> and theres cli that are responsible for clearing or flagging bot records based on new IP added to the spiders directory
[20:27] <tdonohue> mdiggory: I did get that, I'd just say that "long after" is relative. It could be that it's "good enough" for many sites to do bot identification as of today, and then assume it's OK.
[20:27] <mdiggory> so, in that case being able to match on records that are bots needs to retain some variant of the IP
[20:28] <mdiggory> You may not say that if your stats get bloated with bot events that you can no longer tell were bots.
[20:29] * tdonohue may need to table this discussion shortly. very interesting discussion, but we likely shouldn't take all meeting on it -- still, these are great brainstorms
[20:29] <ablemann> ....like the hash of it?
[20:29] <mdiggory> remember this is stats, they may be the worse king of lies, but we do try to minimize the error and achieve some level of accuracy
[20:29] <mhwood> Make it configurable? If your local law is persnickety then you turn it off and lose the ability to bot-flag retroactively; otherwise you can turn it on.
[20:30] <tdonohue> mdiggory: stats are always 'relative' and accuracy is never a given. The only way to truly be sure about whether an IP could be a bot would be to keep it 'forever' and keep checking (and even then, you still may not be right).
[20:30] <hpottinger> I do think there are use cases for keeping some record of an IP address, if it's legal for you to do so, i.e. some researchers might want to know # of downloads from various known institutional ranges
[20:30] <mdiggory> hpottinger: interesting point...
[20:31] <mhwood> Yes, but that goes back to the "specific problem" argument: if you want to extract more, add an extractor.
[20:31] <mdiggory> I suspect the appropriate case even then is to abstract it to some "state" like" oncampus" / "offcampus"
[20:31] <mhwood> interface StackableLogMassager....
[20:33] <tdonohue> could also think about just making it 'semi-anonymous'....cut off the last part of the IP, so that "127.0.0.1" becomes "127.0.0" at some point...then, you still know *something* about where that came from, but it's not exact. Just a brainstorm
[20:33] <tdonohue> in any case, we probably should close up this discussion here shortly
[20:33] <hpottinger> mdiggory: requires that you know what you're looking for ahead of time, but I agree, that's probably the best approach
[20:34] * mhwood notes that many many addresses are effectively anonymized at the other end due to dynamic allocation, NAT, etc.
[20:34] <mhwood> The point being, not that we don't need to address this, but that the quality of the data is already iffy.
[20:35] <tdonohue> ok, shall we move on to other topics now? We should post these discussion notes to DS-955
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-955 ] - [#DS-955] Anonymize IP-Logging to comply to privacy laws - DuraSpace JIRA
[20:35] <mdiggory> yes, please edit out my vampire references ;-)
[20:35] <mhwood> Yes, time to go away and think.
[20:36] <tdonohue> or, we'll just hash your name -- no one will ever know that it was "mdiggory" ;)
[20:36] <mdiggory> hahaha
[20:36] <tdonohue> ok. moving on. Quick announcements (jump in if you have comments, otherwise, I'll make this quick)
[20:37] <tdonohue> 1.8.2 will be released on Thurs & announced Fri. Contact Tim if you have any last additions (but I'd recommend not adding anything else at this point)
[20:37] <mdiggory> excellent
[20:37] <tdonohue> Developers Virtual Summit is every day next week (20:00UTC) -- see: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-27+-+Virtual+Summit for more details
[20:37] <kompewter> [ DevMtg 2012-02-27 - Virtual Summit - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-27+-+Virtual+Summit
[20:37] <tdonohue> Finally, as mentioned before we need to start brainstorming some project ideas for GSoC 2012: https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:37] <kompewter> [ DSpace Summer of Code Ideas - Google Summer of Code - DuraSpace Wiki ] - https://wiki.duraspace.org/display/GSOC/DSpace+Summer+of+Code+Ideas
[20:38] <tdonohue> ok. that's it for quick announcements.
[20:38] <richardrodgers> tdonohue: what did we settle on as communication channel for Virtual Summit?
[20:38] <mdiggory> tdonohue: do we need to jump through organization registration deadlines soon?
[20:38] <tdonohue> Virtual Summit will be via Skype (voice only), with an IRC "backchannel" (for sharing links, etc)
[20:38] <mdiggory> morse code...
[20:39] <tdonohue> See the wiki page for connection details: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-27+-+Virtual+Summit#DevMtg2012-02-27-VirtualSummit-ConnectionInstructions
[20:39] <richardrodgers> hashed
[20:39] <kompewter> [ DevMtg 2012-02-27 - Virtual Summit - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-27+-+Virtual+Summit#DevMtg2012-02-27-VirtualSummit-ConnectionInstructions
[20:40] <richardrodgers> k, thanks
[20:40] <tdonohue> As for GSoC. Yes, DuraSpace will be putting in an GSoC Mentoring Application in near future. Google starts accepting these applications as of Monday, Feb 27 until Fri, March 9
[20:42] <tdonohue> So, to answer mdiggory's question, DuraSpace is "on top of" the application process. We'll get our application in on time, and we expect to be accepted (as we have in the past). So, we might as well start brainstorming ideas already to get a head start
[20:43] <mdiggory> I think we should suggest using 3d printers to produce DSpace code.
[20:43] <tdonohue> Ok. So, the final topic I had for today was 3.0 features, etc
[20:44] <tdonohue> A few small updates on 3.0 "team leader" -- it sounds like kshepherd is going to volunteer to lead the release team (not yet official, but close I think)
[20:46] * mdiggory imagines kshepher1 had no knowledge of this prior to this last statement
[20:46] <tdonohue> Do we want to start talking potential 3.0 features? It'd be nice to start to get some ideas/proposals down
[20:46] <tdonohue> mdiggory -- that's not true ;)
[20:47] <tdonohue> so, ideas for 3.0? Anything anyone wants to throw out there? Or are we all waiting for the Summit next week to hash this out?
[20:47] <hpottinger> I'd like to see streaming and embedded viewer example theme make it in for 3.0, one way or another.
[20:48] <mdiggory> I'm thinking of completely replacing Browse and Search with Discovery
[20:48] <tdonohue> +1 hpottinger -- would be a flashy feature, I think
[20:48] <hpottinger> ixnay on the ashflay ;-)
[20:49] <mhwood> agreedway.
[20:49] <tdonohue> haha
[20:50] <tdonohue> mdiggory -- I also like that idea (I dislike maintaining multiple browse/search options long term). would be interested to know what others think on that too though
[20:51] <mhwood> Plumbing renovation: data model revamp, metadata for all, common authorization aspect across all interfaces.
[20:51] <hpottinger> other things: metadata for all objects, death to dcvalue...
[20:51] <ablemann> cleanup permissions system?
[20:51] <richardrodgers> I like having it as an option, but I don't like requiring it. That's a mandatory new dependency (Solr) which not everyone would want
[20:52] <mdiggory> there are benefits to the consolidation that include:
[20:52] <tdonohue> +1 to lots of plumbing and all those ideas that mhwood, hpottinger & ablemann say. Just a matter of choosing where to get started & how much we can actually get done in time for 3.0
[20:52] <mdiggory> a.) less confusion on what DSpace supports from search features
[20:52] <tdonohue> (and obviously finding some volunteer "plumbers" to help with plumbing -- it's not the most exciting of duties all the time, but it's desperately needed)
[20:52] <mhwood> Split Browse and Search out. Install Core DSpace and your choice of browse/search plugin.
[20:53] <mdiggory> 2.) consolidation of services such as feeds, open search and oai onto on single source (solr)
[20:53] <mdiggory> 3.) have only one central point to address the topic of restricting private items, Collections or Communities from showing in the users search results.
[20:54] <hpottinger> ongoing MDS work should probably come on in for 3.0, and it's been on the list for a while, but common business logic tier is on my list of things that need attention
[20:55] <mdiggory> MDS?
[20:55] <tdonohue> +1000 (can I vote that many times?) for "common business logic tier"
[20:55] <hpottinger> modern DSpace, Richard's project
[20:55] <tdonohue> MDS = Modernized DSpace = https://github.com/richardrodgers/mds
[20:55] <kompewter> [ richardrodgers/mds - GitHub ] - https://github.com/richardrodgers/mds
[20:56] <mdiggory> oh yes, thanks
[20:56] <tdonohue> MDS is essentially already doing some underlying 'plumbing' / cleanup of things that need it. So, it might be a good thing to build off of for those wanting to dig into even more plumbing
[20:56] <mdiggory> note, theres a few things hpottinger and I have been exchanging concerning using WebMVC that suggest one approach for defining what might be considered to be buisness services
[20:58] <tdonohue> would be interested to hear more about these WebMVC / business services ideas/thoughts (maybe @ Summit next week)
[20:58] <richardrodgers> is there a writeup somewhere mdiggory ?
[20:59] <tdonohue> or if there's another way to bring these discussions into a more public realm that'd be good too.. (as richardrodgers just said)
[20:59] <hpottinger> mdiggory: you mentioned you might have some code to point at, on the datadryad site, would you be able to share this... and richardrodgers beat me to the question :-)
[20:59] <mdiggory> That is, defining business services in spring and using WebMVC controllers as a means to define a business service and have it be actionable, with alternative view representations depending on client content negotiation... ie, REST vs Webbrowser, etc
[21:00] <hpottinger> the conversation started with me asking about implementing mdiggory's ideas for disseminator framework (GsOC proposal from last year)
[21:00] <mdiggory> Well, whats ont he Dryad website is some work around a proof of concept that Cocoon can be "isolated" and treated as just a View technology for SPring WebMVC
[21:02] <hpottinger> s/GsOC/GSoC/
[21:02] <kompewter> hpottinger meant to say: the conversation started with me asking about implementing mdiggory's ideas for disseminator framework (GSoC proposal from last year)
[21:02] <mdiggory> and additionally that we can express externally available "Disseminations" of DSpace resources extensibly in WebMVC controllers and mediate the contentype of the returned response based on what the client is requesting for the returned content type, REST, JSPN, HMTL soon
[21:03] <tdonohue> interesting idea (if I understand it correctly). Would be nice to share links to this discussion if it's public
[21:03] <mdiggory> the takehome point is that work on the Freemarker DSpace webapp and the XMLUI webapp can be aligned specifically on WebMVC
[21:03] <PeterDietz> JSPN is not JSON?
[21:04] <mdiggory> P and O are very close together ;-)
[21:04] <mdiggory> soon so on
[21:05] <mdiggory> anyhow, we've just been throwing around ideas, the work Dryad was there to support the use of alternative identifiers for resolving DSpace resources...
[21:05] <mdiggory> http://dev.datadryad.org/resource/doi:10.5061/dryad.1385.2
[21:05] <kompewter> [ Data from: pubyou Contrasting pattern of natural variation in global Drosophila melanogaster populations ] - http://dev.datadryad.org/resource/doi:10.5061/dryad.1385.2
[21:06] <mdiggory> And the exposure of "Disseminations of the Item that may include exports, citations, etc
[21:06] <mdiggory> http://dev.datadryad.org/resource/doi:10.5061/dryad.1385.2/citation/ris
[21:06] <mdiggory> http://dev.datadryad.org/resource/doi:10.5061/dryad.1385.2/citation/bib
[21:06] <tdonohue> admittedly, when I think "common business logic tier", I also think "common API that non-Java apps could also go against" (like recent discussions on lists around building alternative, non-Java web UIs on DSpace). Not sure if this WebMVC idea would cover that..
[21:07] <mdiggory> this uses Spring MVC rather than Cocoon as the controller
[21:07] <tdonohue> but, that's something we could discuss in much more detail next week, if we wanted
[21:07] <mdiggory> It has been used in such cases outside DSpace
[21:08] <mdiggory> starting in 2009
[21:08] <mdiggory> http://blog.springsource.org/2009/03/08/rest-in-spring-3-mvc/
[21:08] <kompewter> [ REST in Spring 3: @MVC | SpringSource Team Blog ] - http://blog.springsource.org/2009/03/08/rest-in-spring-3-mvc/
[21:08] <tdonohue> oh, true. duh, if there's a REST API, there's a way
[21:08] <richardrodgers> I do think at some point we need to have a hard look at Cocoon viability for 'next-gen' UI frameworks.....
[21:09] <tdonohue> sounds like a good discussion for next week as well, I'd be interested to chat about that too, richardrodgers
[21:09] <PeterDietz> I'm not loving the idea of building against DRI
[21:09] <mdiggory> I took this idea to Bojan as well as a future direction to take that DSpace REST services in
[21:11] * tdonohue notes we are in "overtime". Not gonna stop this discussion though -- good brainstorms of potential topics for next week's summit. (but if you need to leave, you are obviously welcome to catch up later via logs)
[21:11] <PeterDietz> I like the webmvc @annotation syntax. It would seem like a very natural fit for a web service API. Although, someone could do any other java webapp framework. Or even implement a rest api in a JRuby JVM
[21:11] <mdiggory> richardrodgers: thats one of the reasons I start to favor WebMVC, because it does provide for alterative view approaches outside of Cocoon, the most significant point made thusfar about the common business tier is that there is business logic captured in xmlu, jspui, rest and now the freemarker UI that it would be beneficial to extract out and maintain separately.
[21:13] <mdiggory> the direction of development would be to support the WebMVC feature initially, then start to migrate the business logic out of cocoon javscript and various "Utils" classes into a set of common classes that could easily be wire together in WebMVC or just a plain old java, so on...
[21:14] <hpottinger> +1 I like the sound of this, sign me up :-)
[21:15] <mdiggory> that WebMVC would just be a mechanism to get us migrating code in XMLUI, Freemarker and JSPUI and place it somewhere common to test interfaces
[21:15] <tdonohue> so, by "WebMVC", I'm realizing mdiggory is talking about the stuff/business logic *under* the "Freemarker UI" and not the entire thing (which is what graham initially called the "WebMVC"). Just wanted to clarify that there may be a few definitions of WebMVC floating around
[21:15] <PeterDietz> All I need to start doing some of the wrench work of refactoring that, is a direction of what coding paradigm to use for folding the business services into somewhere common.
[21:16] <mdiggory> right, Freemarker is a templating language for presentation, like Velocity, or in the Cocoon case, XSP
[21:16] <mdiggory> Freemarker is the view, WebMVC is the Framework
[21:16] <tdonohue> yea, i understand mdiggory. Just wanting to make sure all are on the same page. It gets confusing if we aren't all understanding what you mean by "WebMVC".
[21:17] <mdiggory> ie, liek struts and JSP... blaa blaa blaa
[21:17] <mdiggory> http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html
[21:17] <kompewter> [ 16. Web MVC framework ] - http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html
[21:18] <tdonohue> yep, gotcha. just noting that Graham defines it as: "WebMVC is the new user interface for DSpace built on top of Spring's WebMVC Framework". We need to tease this apart a bit, as it could get confusing: https://wiki.duraspace.org/display/DSPACE/WebMVC+%28Freemarker%29+UI
[21:18] <kompewter> [ WebMVC (Freemarker) UI - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/WebMVC+%28Freemarker%29+UI
[21:18] <PeterDietz> even in github.com/dspace/webmvc, only a portion of it is WebMVC, thats all the java controllers.. see the root directory https://github.com/DSpace/webmvc
[21:18] <kompewter> [ DSpace/webmvc - GitHub ] - https://github.com/DSpace/webmvc
[21:18] <PeterDietz> freemarker-themes, freemarker-webapp, webmvc-api
[21:19] <richardrodgers> I've got to run, but one thing I'm hoping to begin playing with in mds is the notion of different kinds of 'modules': some are application modules (web apps, cmd-line apps), and some are 'business logic' modules (libraries that support the apps)
[21:20] <KevinVdV> Need to run also, until next week !
[21:20] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: Want to be different? Try HydraIRC -> http://www.hydrairc.com <-)
[21:20] <mdiggory> An added benefit of doing this in XMLUI means that we can consolidate services like RSS/ATOM/OpenSearch away from cocoon and reuse them. That using WebMVC, one can stop having to hack sitemap.xmap to add these features which are not really truly benefiting from the XML Pipeline of Cocoon.
[21:20] <richardrodgers> bye all
[21:21] <tdonohue> We may just want to rename the DSpace WebMVC project eventually -- it's more than just a WebMVC API, as PeterDietz notes. I just don't want to get in areas where we get confused about what we mean by WebMVC (the project? the UI? the Spring framework?)
[21:21] * richardrodgers (~richardro@18.111.47.178) Quit (Quit: richardrodgers)
[21:21] <mdiggory> maybe
[21:22] <PeterDietz> if there was more development happening on webmvc project, it might make sense to do that, but the only commits are Graham, myself, and Robert (from GSoC)
[21:22] <mdiggory> but, I can live with it as long as we realize that what we may be attempting to do is use it as a means to an end
[21:22] <mhwood> Sounds like it's two projects: a Freemarker UI and the Spring support for it.
[21:22] <tdonohue> +1 mhwood
[21:23] <mdiggory> the "means to an end" is separating out business logic from presentation tiers when it is possible.
[21:23] <mdiggory> that business logic would probably just be POJOs or Beans, not explicitly WebMVC/Spring
[21:24] <PeterDietz> yep, the DSpace webmvc project the freemarker is currently tightly bound to webmvc. the controllers say something like:
[21:24] <PeterDietz> protected String displayHome() throws Exception {
[21:24] <PeterDietz> return "pages/home";
[21:24] <PeterDietz> }
[21:24] <PeterDietz> and pages/home is freemarker stuff
[21:24] <mdiggory> PeterDietz: yes, but, tbh, that example is not tightly bound ;-)
[21:25] <PeterDietz> tightly schmightly
[21:25] <mdiggory> because depending on the Controller and View technology you configure on the backside "pages/home" could mean anything
[21:26] <mdiggory> If you use the ContentNegotiatingViewResolver you can configure more than one view solution based on client capabilities
[21:27] * mhwood tries to suppress a vision of a website on which each page is rendered with a different one of the many many templating engines....
[21:27] <mdiggory> yea, I certainly did not mean that ;-)
[21:27] <tdonohue> mhwood just scared me
[21:27] <mdiggory> he like to do that
[21:28] * tdonohue shivers
[21:28] <hpottinger> PeterDietz and mdiggory, what do we need to get things going? Manifesto on the wall? White board?
[21:28] <mdiggory> Minions...
[21:29] <mdiggory> many many Minions
[21:29] <tdonohue> you can always recruit minions ;)
[21:29] <PeterDietz> I'm wondering if I need to read mdiggory's services manifesto again.. But I'll still need a poking that says "make a CollectionAdminService in ...", and then have your ,,, use that
[21:29] <tdonohue> (though they may prefer to be called "volunteers")
[21:30] * hpottinger has already signed on
[21:31] <hpottinger> I can conscript others, but will need a rallying cry
[21:33] <mhwood> 4 out of 5 Doctors Recommend WebMVC?
[21:33] <mdiggory> Minions Assemble! http://www.youtube.com/watch?v=hzMnYxxwmGU
[21:33] <kompewter> [ MINIONS ASSEMBLE - YouTube ] - http://www.youtube.com/watch?v=hzMnYxxwmGU
[21:33] <PeterDietz> mdiggory: java.lang.RuntimeException: ElemTemplateElement error: The xsl:variable element must not have both content and a select attribute.
[21:33] <PeterDietz> http://dev.datadryad.org/discover?field=dc.contributor.author_filter&fq=location:l2&fq=dc.contributor.author_filter%3Aabad%C3%ADa%5C-cardoso%2C%5C+alicia%5C%7C%5C%7C%5C%7CAbad%C3%ADa%5C-Cardoso%2C%5C+Alicia
[21:33] <mdiggory> Hey, stop that!
[21:34] <mdiggory> Its called dev for a reason !
[21:34] <PeterDietz> ahh, didn't observe.. If I find anything on the internet, I automatically assume its some type of truth
[21:35] <hpottinger> there are many types of truth
[21:35] <mdiggory> anyhow, its now being address ;-) thanks for pointing it out
[21:35] <tdonohue> I'd be willing to sign up as well to help with a "business services tier". So, I'd also be a volunteer/minion.
[21:36] <mdiggory> Other topics for 3.0 - I'd like to add the DSpace Item Level Versioning work thats also in Dryad.
[21:36] <tdonohue> We may just need to find ways to "make this happen" -- could even try something like a "virtual hackathon" of sorts to crank out some code, if we can get our various institutions to signoff on it.
[21:37] <hpottinger> +1 to hackathon
[21:38] <PeterDietz> My hackathon project would be to build a Ruby on Rails client that solely consumes web services for all its data.
[21:39] <mdiggory> Additionally, the IdentifierService work that supports the /resource/ service that supports external DOI services... https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/identifier-services/
[21:39] <kompewter> [ dryad - Revision 5287: /trunk/dryad/dspace/modules/identifier-services ] - https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/identifier-services/
[21:40] <tdonohue> PeterDietz -- I'd also be interested in seeing something like that
[21:40] <mdiggory> RoR freaks...
[21:40] <mdiggory> opse sorry, did I say that?!
[21:41] <PeterDietz> food coloring and fructose are cheap these days.. thus plenty of kool-aid
[21:41] <mdiggory> yes I agree actually reaching a point where the REST services are nailed down as to support actual client examples would be a good thing
[21:42] <PeterDietz> ohh. I think we need to open the voting process for GitHub
[21:42] <mdiggory> PeterDietz: bug fixed...
[21:42] <hpottinger> +1 GitHub :-)
[21:44] <mdiggory> So PeterDietz did you start pushing changes in Github back to svn?
[21:44] <tdonohue> The goal for the REST API should definitely be to support actual clients like RoR or similar. The more we can enable new UIs to be built on DSpace, the better off DSpace will be long term.
[21:44] <PeterDietz> GitHub will never sync down to duraspace's SVN server
[21:45] <PeterDietz> if you want to "svn co" the code. use svn.github.com
[21:46] <PeterDietz> https://github.com/blog/966-improved-subversion-client-support
[21:46] <kompewter> [ Improved Subversion Client Support - GitHub ] - https://github.com/blog/966-improved-subversion-client-support
[21:47] <tdonohue> yea, if we move to GitHub, we won't maintain SVN anymore. So, syncing will stop
[21:48] <mdiggory> yes, and the svn support can be used as a stepping stone it would seem.
[21:48] <tdonohue> FYI - I plan on calling the official GitHub vote next week via dspace-devel, as I think we said we'd give folks until end of Feb
[21:48] <hpottinger> perhaps a redirect from SVN to the github svn would be helpful?
[21:49] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[21:49] <mdiggory> which in that case I'm all for switching, but what about the various projects that reside in modules and sandbox?
[21:49] <tdonohue> yea, we can redirect SVN to github. We also will put an "archive" of the SVN up to svn.duraspace.org (alongside the old archived SVN for Fedora, before they moved to GitHub)
[21:50] <tdonohue> mdiggory -- they'd also need to switch to GitHub, or we'd have to just leave them in an SVN "archive" indefinitely
[21:50] <hpottinger> the nice thing about redirects is the SVN client nags you to switch your code base, it's nice that it "still works" but also tells you "you're doing it wrong"
[21:51] <mdiggory> so, we loose the fine grained permissions, but I think we are reaching a point where we would create separate repositories for individual addon modules?
[21:51] <tdonohue> e.g., here's Fedora's old SVN archive -- it has all their old code from before they moved to GitHub, but it now has a README: https://svn.duraspace.org/fcrepo-mirror/moved-to-github/MOVED-README.txt
[21:54] <PeterDietz> no more fine grain. If you want fine grain, then that person is not a committer, they fork it, and you accept their pull-requests
[21:54] <mdiggory> but we have projects in modules that DSpace is dependent on that need to be maintained in parallel in Git
[21:55] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-xmlui-lang/
[21:55] <kompewter> [ repo - Revision 6948: /modules/dspace-xmlui-lang ] - http://scm.dspace.org/svn/repo/modules/dspace-xmlui-lang/
[21:55] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-api-lang/
[21:55] <kompewter> [ repo - Revision 6948: /modules/dspace-api-lang ] - http://scm.dspace.org/svn/repo/modules/dspace-api-lang/
[21:55] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-cocoon-servlet-service-impl/
[21:55] <kompewter> [ repo - Revision 6948: /modules/dspace-cocoon-servlet-service-impl ] - http://scm.dspace.org/svn/repo/modules/dspace-cocoon-servlet-service-impl/
[21:55] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-geoip/
[21:55] <kompewter> [ repo - Revision 6948: /modules/dspace-geoip ] - http://scm.dspace.org/svn/repo/modules/dspace-geoip/
[21:56] <tdonohue> mdiggory -- anything we need to maintain going forward would move to DSpace's GitHub: https://github.com/DSpace/
[21:56] <kompewter> [ DSpace's Profile - GitHub ] - https://github.com/DSpace/
[21:57] <mdiggory> and thats what I'm talking about
[21:57] <tdonohue> So, we'd likely have a http://github.com/DSpace/dspace-xmlui-lang/ , for example (doesn't exist yet obviously)
[21:57] <mdiggory> the structure of that.
[21:57] <PeterDietz> mdiggory: We'll have to solve maven release problems that will creep up in the future. And rewire the poms to work that way
[21:58] <mdiggory> I assume the Maven release process supports git as well
[21:58] <tdonohue> but, anything that is *not* being maintained (e.g. old sandbox stuff) could just sit in the SVN Archive -- if we ever decide to pick it back up again, we could move it to GitHub then
[21:58] <tdonohue> yes, Fedora uses Maven + Git + Sonatype
[21:58] <mdiggory> http://www.sonatype.com/people/2009/09/maven-tips-and-tricks-using-github/
[21:58] <kompewter> [ Sonatype Blog » Maven Tips and Tricks: Using GitHub ] - http://www.sonatype.com/people/2009/09/maven-tips-and-tricks-using-github/
[21:59] <mdiggory> seems like you could complete the release entirely in your own local clone then push the changes to github, right?
[22:01] <mdiggory> I ponder if that might ease release noise of those interim release commits prior tagging.
[22:01] <mhwood> I've got to stop scaring people and go home now. 'bye all.
[22:01] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:02] <tdonohue> I think the 'mvn release:prepare' does pushes to GitHub, so that a tag gets generated in GitHub (at least that's what it looks like from the processing logs under Step #10 on that sonatype link above)
[22:02] <mdiggory> yea, I just read that as well
[22:03] <mdiggory> http://pettermahlen.com/2010/02/20/git-and-maven/
[22:03] <kompewter> [ Git and Maven « Petter Måhlén's Blog ] - http://pettermahlen.com/2010/02/20/git-and-maven/
[22:04] * PeterDietz I'm migrating DSpace-REST to GitHub right now.. I've been talking about this for months, and now is as good a time to move it.
[22:04] <mdiggory> opse, I have to run as well now, bye
[22:05] <mdiggory> PeterDietz: go for it...
[22:06] <tdonohue> +1 PeterDietz -- awesome!
[22:07] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has left #duraspace
[22:10] <PeterDietz> I'm guessing success: https://github.com/DSpace/dspace-rest/commits/master/
[22:10] <kompewter> [ Commit History for DSpace/dspace-rest - GitHub ] - https://github.com/DSpace/dspace-rest/commits/master/
[22:10] <PeterDietz> now.. to incorporate HedTek's improvements
[22:15] <tdonohue> yep, definitely. Let us know how that goes -- it seems like HedTek has done a lot of great stuff already
[22:56] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[23:08] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:11] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[23:54] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Ping timeout: 252 seconds)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.