Timestamps are in GMT/BST.
[0:27] * snail (~stuart@130.195.179.88) Quit (Ping timeout: 240 seconds)
[0:41] * snail (~stuart@130.195.179.88) has joined #duraspace
[3:19] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[3:27] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) Quit (Quit: Leaving.)
[4:21] * scottatm (~scottatm@adhcp136.evans.tamu.edu) Quit (*.net *.split)
[4:21] * ianthe (~ianthe@cowu.be) Quit (*.net *.split)
[4:22] * snail (~stuart@130.195.179.88) Quit (*.net *.split)
[4:25] * snail (~stuart@130.195.179.88) has joined #duraspace
[4:25] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[4:25] * ianthe (~ianthe@cowu.be) has joined #duraspace
[6:52] -card.freenode.net- *** Looking up your hostname...
[6:52] -card.freenode.net- *** Checking Ident
[6:52] -card.freenode.net- *** Found your hostname
[6:52] -card.freenode.net- *** No Ident response
[6:52] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:52] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:52] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:21] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[8:55] * grahamtriggs (~grahamtri@62.189.56.2) has joined #duraspace
[12:35] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[13:17] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:17] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Client Quit)
[13:18] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:36] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) has joined #duraspace
[13:51] * neanlos (be90a357@gateway/web/freenode/ip.190.144.163.87) has joined #duraspace
[13:59] -card.freenode.net- *** Looking up your hostname...
[13:59] -card.freenode.net- *** Checking Ident
[13:59] -card.freenode.net- *** Found your hostname
[13:59] -card.freenode.net- *** No Ident response
[13:59] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[13:59] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[13:59] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[14:24] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:53] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) has joined #duraspace
[14:53] * ksclarke1 (~kevin@156-56-58-106.dhcp-bl.indiana.edu) Quit (Quit: Leaving.)
[16:53] * granitize (~Adium@137.149.66.159) has joined #duraspace
[16:57] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) Quit (Quit: Leaving.)
[17:59] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) has joined #duraspace
[18:04] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) Quit (Client Quit)
[18:04] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) has joined #duraspace
[18:40] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:06] * tdonohue (~Adium@156-56-59-43.dhcp-bl.indiana.edu) has joined #duraspace
[19:10] * tdonohue (~Adium@156-56-59-43.dhcp-bl.indiana.edu) has left #duraspace
[19:43] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:55] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) Quit (Ping timeout: 276 seconds)
[19:55] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) has joined #duraspace
[19:55] * PeterDietz (~PeterDiet@128.146.175.194) has joined #duraspace
[19:56] * keithg (~keith-noa@207.138.47.158) has joined #duraspace
[19:57] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) has joined #duraspace
[19:58] * mdiggory1 (~androirc@184-194-235-65.pools.spcsdns.net) has joined #duraspace
[19:58] <PeterDietz> hi all dspace developers meeting in just a few minutes
[20:00] <mdiggory1> Suspect many are at code 4 lib?
[20:00] * tdonohue (~Adium@156-56-59-43.dhcp-bl.indiana.edu) has joined #duraspace
[20:00] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[20:00] <PeterDietz> I know tdonohue is at code4lib
[20:00] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:00] * tdonohue is lurking…from code4lib :)
[20:01] <mdiggory1> Trying to do this from an android phone, should be interesting
[20:01] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) has joined #duraspace
[20:01] <PeterDietz> ahh, ok, since many are at code4lib, I'll not do ustream
[20:01] <PeterDietz> that might be weird, esp for mobile users, people in auditorium, etc
[20:02] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) Quit (Ping timeout: 245 seconds)
[20:02] <mdiggory1> Dads
[20:02] <PeterDietz> so, let me begin by saying thanks for coming, I want to cover what I like about git. And you all say... but you can do that in SVN, then I rebut and say its even better in git
[20:03] <richardrodgers> how much do the shills get paid ;)
[20:03] <PeterDietz> ok, so for starters, I created a clone of dspace in git, just for experimentation purposes: its on github https://github.com/DSpace/DSpace
[20:03] <mdiggory1> All I care about is what happens to modules ... ;)
[20:04] <PeterDietz> if you're a shill, you've already gotten your fortune cookie with prepared statement, and 20 cent off coupon to your nearest gas/petrol station
[20:04] <PeterDietz> if you haven't gotten the fortune cookie, than I imagine that you'll already poke holes in this discussion. here goes
[20:04] <PeterDietz> First, I've created a copy of dspace in git.. https://github.com/DSpace/DSpace
[20:05] <mdiggory1> Very nice
[20:05] <PeterDietz> if you've got git installed on your machine, you can obtain the code by doing
[20:05] <PeterDietz> git clone git://github.com/DSpace/DSpace.git dspace
[20:06] <grahamtriggs_> that's just a website - doesn't tell us much about the day to day experience ;)
[20:06] <PeterDietz> it will then pack it all up just like svn obtains the code.. but nicer
[20:06] <PeterDietz> Cloning into dspace...
[20:06] <PeterDietz> remote: Counting objects: 22823, done.
[20:06] <PeterDietz> remote: Compressing objects: 100% (5573/5573), done.
[20:06] <PeterDietz> remote: Total 22823 (delta 12986), reused 22823 (delta 12986)
[20:06] <PeterDietz> Receiving objects: 100% (22823/22823), 23.93 MiB | 273 KiB/s, done.
[20:06] <PeterDietz> Resolving deltas: 100% (12986/12986), done.
[20:07] <PeterDietz> some smarts going on there, computing diffs for efficient commute across the wire
[20:07] <grahamtriggs_> actually, I'm largely sold on the technical merit of git over svn - the big question is how big an impact would it be for us to move away from svn
[20:07] <PeterDietz> ohh, worse pain than colonoscopy I imagine, but it would only take a short while
[20:08] <PeterDietz> You also have to think of new workflows for how people commit, and how you yourself commit
[20:09] <mdiggory1> My concern is what about modules... We are trying to actually separatw apart and maintain an endorsed set of addons.
[20:09] <PeterDietz> ..as in, you would clone that to your computer, and in svn you don't make any commits, until its perfect, then you commit back to central server. so your source code spends several days/weeks being blue (visual color of being changed)
[20:10] <PeterDietz> ahh, so get to the point where this git discussion becomes relevant to us trying to organize our code, and how this might help that
[20:10] <mdiggory1> My current goal is to get stats and discovery back under modules
[20:10] <PeterDietz> so in svn you have svn:externals, where you define that a certain folder in the repo is tracked in a different repository..
[20:11] <mdiggory1> Likewise make dspace dependent on more of those modules
[20:11] <PeterDietz> git has something called submodules, which functions similarly. if you're really keen, you'll learn about git subtree merge, which I'm not discussing now
[20:11] <PeterDietz> so you could have:
[20:11] <PeterDietz> dspace dspace-api dspace-discovery dspace-jspui dspace-lni dspace-oai dspace-stats dspace-sword dspace-xmlui LICENSE NOTICE pom.xml README
[20:11] <mdiggory1> elaborate
[20:12] <PeterDietz> maybe dspace, dspace-api, README, pom would all live in github/DSPACE
[20:12] <PeterDietz> github/dspace-discovery, github/dspace-jspui, ... could all be seperate repositories
[20:13] <PeterDietz> then in github/DSPACE, you add a module: git submodule add dspace-discovery dspace-discovery
[20:13] <PeterDietz> git submodule init
[20:13] <PeterDietz> git submodule update
[20:14] <grahamtriggs_> unless it makes a difference for permissions, I don't see the point in that regard - either it's part of 'core', or it's a dependency on a published artefact, and the source for that artefact is separate
[20:14] <mdiggory1> It may possibly work with our current intwllij aporoach
[20:16] <PeterDietz> for permissions in git, its somewhat different than svn.. in svn only the "committers" have write access in svn/trunk, so to make a code change, only "we" can do that
[20:17] <PeterDietz> in git, it will be that everyone has commit ability to commit locally to their own computer, so think Sue from NASA, if she has a certain fix, she makes it to her codebase, then sort of sends an email that says hey, look at this new feature in my repository
[20:17] <mdiggory1> My goal is to get the assembly working on released artifacts, not source, you override a binary artifact by checking out its source. So separate submodules or repos does sound like it would allow you to pixk and choose
[20:17] <PeterDietz> if a "committer" sees that and likes it, they can then pull / merge her change into the github/DSPACE tree
[20:18] * mdiggory1 (~androirc@184-194-235-65.pools.spcsdns.net) Quit (Quit: AndroIRC)
[20:18] * mdiggory1 (~androirc@184-194-235-65.pools.spcsdns.net) has joined #duraspace
[20:18] <richardrodgers> So PeterDietz : does that manage 'stale' patch better than svn?
[20:19] <PeterDietz> Git isn't going to be helpful for swapping out binary artifacts, that might exist in some maven repo. but its a good way to manage source code
[20:19] <mdiggory1> True
[20:20] <PeterDietz> svn we create a patch by saying svn diff > ds-666.patch
[20:21] <PeterDietz> then you get a patch against svn-commit-6023 (trunk at the time).. it becomes stale as time passes, and now trunk is at svn-commit-7000, and now your patch is not able to be run
[20:21] <grahamtriggs_> and cross our fingers and hope that it works at either end...
[20:22] <PeterDietz> in git, "i think" this works better. Typically git does this recursive replay thing, where you could check out the code to the git-equivalent of svn-6023, apply the patch, then replay history of 6024..7000
[20:22] <mhwood> This is why one has to grow a reflex to start the day with 'svn update'
[20:22] <mdiggory1> My concern is that wee should be striving to get less enduser modifications happening to core code. We need mire api contracts and lrsd overiding of org.dspace.content. Whike totally possibke no matter the repo tech. We need to have more guidelines
[20:23] <PeterDietz> mark said: "more api contracts", and "less overriding"
[20:23] <mdiggory1> Mire = more lrsd = less
[20:23] <mdiggory1> Yhanks
[20:23] <grahamtriggs_> from my limited experience, git is much better at accurately merging than svn (branch merging is a massive pain in svn)
[20:23] <PeterDietz> mark said: Yankees
[20:23] <mdiggory1> Hehe
[20:25] <PeterDietz> I'm somewhat with you on saying don't touch dspace-api, however I look at dspace-api, and I think org.dspace.content.Collections.findAll is EXTREMELY inefficient at computing if this user is allowed to submit to a certain collection
[20:25] <mdiggory1> Yes goid example
[20:26] <mdiggory1> Not that the improvement is needed, it us
[20:26] <PeterDietz> doing several queries for each collection, so 3N queries as opposed to 4 queires max.. I might be differant then average user though
[20:26] <PeterDietz> so I would check out a local branch.. git checkout -b collection-to-submit-performance
[20:27] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) Quit (Ping timeout: 240 seconds)
[20:27] <grahamtriggs_> I'm really not bothered about people touching dspace-api. Simple reality, code has to *evolve* - it's not case of "write a Collection object", "write another Collection to replace it", etc. It really doesn't make that much difference where it happens
[20:27] <mdiggory1> Weve discussed needing rearchitecture here and much time has already bern invested
[20:27] <PeterDietz> make several commits locally that this is a sweet improvement, finally I push my branch to github, so you all can see it. Then whoever approves/blesses my code can then merge it into master once its been tested
[20:28] <PeterDietz> thats a cut and dry example of 100% performance improvement that all would want, so it should evolve the core
[20:28] <richardrodgers> So PeterDietz do you find such local or private committing makes you more productive?
[20:29] <PeterDietz> you're more likely to take risks with the code, when you have saved snapshots of your progress every two hours or so, as opposed to once a week
[20:29] <tdonohue> I've heard (here at code4lib) others say that the local/private committing feature of git is sometimes very useful if you want to "save your changes" locally, without affecting others.
[20:30] <tdonohue> so, you may commit locally every day (whether truly complete or not)..and push up to github only once it's "ready" for more eyes.
[20:30] * tdonohue sees that PeterDietz and I are describing the same thing
[20:31] <PeterDietz> You have many branches open at once, so you can multitask in the code: https://picasaweb.google.com/pdietz84/OSULibrariesDSpaceDesigns#5571790014387454498
[20:31] <richardrodgers> but of course you could do that and combine local git with central svn
[20:31] <mhwood> I really would like to be able to do that, but you can't with SVN.
[20:31] * mdiggory1 (~androirc@184-194-235-65.pools.spcsdns.net) Quit (Read error: Connection reset by peer)
[20:31] <grahamtriggs_> although we can have workspaces that allow us to "save our changes" by branching in svn. The key thing here is less about having the capability, but that the management of the git repository is much smoother than svn merging
[20:32] <PeterDietz> with svn its doable, sure, but a major pain, you checkout trunk, make a branch for your feature, work there, merge your stuff back into trunk.
[20:32] <PeterDietz> the branches all live on the server, so every commit you do touches the central server
[20:33] <PeterDietz> one would say the perfomance boost of working offline is useful, such as working on a bus/train/plane/conference-with-spotty-wireless
[20:33] <mhwood> The problem is that you wind up needing to have file X be in two repo.s at once, with SVN. In a DVCS the file is in exactly one repo and you clone it to others.
[20:33] <grahamtriggs_> and pushing it off your 'local' repository is a good thing, as it can be accessible from multiple locations and backed up against machine failure - although one neat trick with git is to establish your repository in a DropBox backed folder
[20:33] <PeterDietz> however, i find it mostly nice to be able to make stupid mistakes in the code locally that nobody else sees
[20:34] <PeterDietz> ohh, i sometimes wish I had dropbox monitoring my NetBeansProjects folder.
[20:34] <PeterDietz> I've accidentally typed git checkout -- path/to/newfeature-thats-never-been-committed
[20:34] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) has joined #duraspace
[20:34] <PeterDietz> instead of git add . ===== git commit -- path/to/feature
[20:35] <PeterDietz> ...which immediately and tracelessly deletes every shred of the uncommited file you had instantly with extreme performance
[20:36] <PeterDietz> the only way I recovered was by happening to have had netbeans do a diff, which then had that diff still visible in the IDE, however if you touched the code, it would instantly reload the file, and grab the fresh/clean code, so i just hand-typed all the changes
[20:36] <PeterDietz> git will probably make your swear, and pound the table a lot for the first while that your learning it
[20:36] <grahamtriggs_> I think the answer to that problem is to have TimeMachine enabled, not DropBox!
[20:36] <PeterDietz> ...which might be a good thing
[20:38] <tdonohue> PeterDietz — have you played much with Git & SVN "syncing"? I've heard this is also possible…develop in Git, and eventually sync back to a central SVN. Not sure how "messy" that gets though.
[20:40] <PeterDietz> there are things you could build into either one, such as post-commit hooks, so you could run the gamut of writing a webservice to tweet the last person who modified the code before the most recent commit and tweet them that their precious code had been altered 17% with 12 additions, 3 deletions, with the message "DS-777 Adding SSL detection"
[20:40] <PeterDietz> ...or simply also commit/sync the change to svn
[20:41] <richardrodgers> Not to dwell on negatives, but how about the maturity of IDE tooling?
[20:41] <PeterDietz> I might prefer to just have a server running a cron-task night to have git pull the latest changes from svn
[20:41] <PeterDietz> yeah, thats a good point
[20:41] <PeterDietz> I'm nervous about doing git commit from any IDE, however I'm perfectly fine doing that for svn through IDE
[20:41] <tdonohue> richardrodgers — I've heard that Eclipse & IDEA have decent Git plugins…but, NetBeans does not. (this is mostly hearsay though)
[20:42] <grahamtriggs_> IntelliJ has built in support (v10 at least) - no idea if it's any good
[20:42] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) has joined #duraspace
[20:42] <kshepherd> late again, sorry all
[20:42] <PeterDietz> netbeans has nbgit plugin, which is good for read access, oracle is working on 1st class git plugin for netbeans
[20:42] <grahamtriggs_> http://code.google.com/p/nbgit/
[20:42] * kshepherd scrolls back
[20:43] <PeterDietz> intelliJ just works with git, so you're all safe there committing into git. They're smart people who've figured it out.
[20:43] <PeterDietz> However intelliJ always makes a bunch of bunk .iml files everywhere and I get upset so turn it off
[20:43] <PeterDietz> ...but then in git you can have a .gitignore file, which allows you the blacklist files from version control
[20:44] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[20:44] * tdonohue unfortunately has to head off to next code4lib session. will catch up with everyone later!
[20:44] <mdiggory> ok, I am back without the andriod handicap
[20:44] <PeterDietz> so *.iml, *.imp, ... can all be gitignored, and git never things about them again
[20:44] * tdonohue (~Adium@156-56-59-43.dhcp-bl.indiana.edu) has left #duraspace
[20:44] * PeterDietz wonders if having full keyboard will improve mdiggory's typo rate
[20:45] <mdiggory> so, I'm not adverse to changing to git.
[20:45] <PeterDietz> also in the case of dspace code, you can say target/ and all the compiled directories are no longer tracked
[20:45] <mdiggory> ratio will be the same, rate will be higher
[20:46] <PeterDietz> Paid shill's in the crowd, time to ask the questions
[20:47] <mdiggory> So, I want to clarify with an example why it is important to not override core classes... the problem arises when you are working on creating multiple addons and contending with local customizations made by a client. There are collisions caused by different groups altering the same file in separate locations.
[20:47] <PeterDietz> Or, if anyone else has questions we should discuss them
[20:47] <richardrodgers> So could we make it possible to make our dev enviornment agnostic to a degree? Modules in git or svn?
[20:47] <mdiggory> overriding is a problem in a modular environment, so is altering the original source and compiling in your own functionality
[20:48] <mdiggory> so for instance, if we need to alter something Item.java in an addon module for dspace, and the client has altered the same class, then modularity goes out the window, differences still need to be merged and maintained
[20:49] <mdiggory> richardrodgers: once I do away with dspace-parent, I believe this is totallypossible
[20:49] <PeterDietz> I've had it with dpsace/module/custom-api and hoping that its changes got into my compiled takes effect code, so I make all my changes directly to dspace-api, dspace-jspui, dspace-xmlui, ...
[20:50] <grahamtriggs_> even if you make it possible to change the functionality without overriding the core class, doesn't mean that you won't have collisions between multiple customizations trying to provide their own implementation
[20:50] <mdiggory> grahamtriggs: api contracts and designations of where overriding is possible eases this
[20:51] <mdiggory> oftentimes when reviewing someones code, I immediately see ways to do away with the customizations the've made.
[20:51] <mhwood> Yes, I gave up using the overlay stuff a long time ago. It takes away a lot of the value of VCS tools, since they don't know that the same concept is written (slightly differently) in two different places.
[20:52] <mdiggory> we extensively use the overlay approach at the moment and it is working fine, we actually track all our own changes to dspace code, and we work to minimize them and utilize the servicemanager and spring to alleviate modifying the core codebase whenever possible
[20:53] <PeterDietz> ...so then in spring you register SOLR to be a UsageEventListener, or once you've written your own implementation in mongoDB, you don't edit dspace-stats, but rather register MONGODB as the UsageEventListener
[20:53] <mdiggory> but it is not perfect.... and what I am trying to get you guys to pay attention to is not the approach overlay vs alter the code in place, but the architecture and what needs to happen to it to reduce the need to do this
[20:54] <mdiggory> PeterDietz: correct, that is one example, but even the EventService / USage Event is not yet fully realized in the core
[20:55] <mdiggory> the fact that you need to alter "Collection" to change "findAll" is the big problem here, it is a huge architectural break
[20:57] <mdiggory> All the work that James Rutherford did is sitting on the floor "rotting" because of choices that were made... His work was going to save the architecture in this area... it is sooo sadd that this has been lost
[20:57] <mhwood> So we are missing some plugin points?
[20:57] <mdiggory> the work of Aaron on the service manager was supposed to join with the work James was doing...
[20:58] <grahamtriggs_> mdiggory: depends on your circumstances. In many cases it may actually be better to take a 'vendor drop' approach to putting customizations into a local source repository and merging the differences during upgrades. Providing alternate implementations of something via configuration doesn't protect you from having two separate modules that want to replace the same piece of functionality, and that you need a
[20:58] <grahamtriggs_> implementation that merges the functionality of both
[20:58] <mdiggory> and liberate the data model so you did not need to change it directly to alter storage or search logic
[20:59] * PeterDietz for the record I found that findAll is simply easy, works fine.. its findAuthorized that I've got the performance gripes with, however don't let that be the distraction
[20:59] <mdiggory> I don't buy it grahamtriggs_ if you have separate modules agreeing on a common api and data model, the points to integrate become much clearer and its then not a hackfest
[21:01] <mdiggory> thnx for correct PeterDietz
[21:02] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[21:03] <mhwood> So do we need to look over a pile of mod.s that people are having to make, figure out where the APIs fall short, and redesign those areas of high customization desire so they are replaceable or have generally useful callouts or whatnot?
[21:03] <mdiggory> we are actually coming up on other problem areas in the API right now, Bitstream.getParent and other such methods that could stand to not be where they are or implemented in the fashion they are... we are working on Item Versioning for Dryad, and its really stressing the data model in its current incarnation
[21:04] <mdiggory> correct mhwood, we need to get back to improving the data model...
[21:04] <mdiggory> Will git improve our ability to do this?
[21:04] <mdiggory> are we going to get more exposure of changes in local instances?
[21:05] <mdiggory> I'm not convinced because that social, not technical
[21:06] <mhwood> That's not the only thing we need to work on, though. Will DVCS help *overall*?
[21:07] <mhwood> And yes, I think that a more granular, more open VCS model would help gain visibility over stuff that people don't think is ready (or perhaps appropriate) for the trunk.
[21:07] * jefftrimble (~jefftrimb@maag127.maag.ysu.edu) Quit (Quit: Leaving)
[21:08] <mdiggory> that would be helpful...
[21:08] <PeterDietz> I was thinking about something from Computer Science 101, where you would say list.sort(), or list.sort(algorithm).. so collection.findAuthorized() might be broke, but what about collection.findAuthorized(locallyCustomizedAlgorithm) ... where locallyCustomizedAlgorithm is in my local codebase edu.osu.kb.Collection as opposed to org.dspace.content.Collection
[21:08] <mhwood> The question I have is: is this the right time to swap VCS models? or will there ever be a right time, as opposed to "get it done and move on"?
[21:09] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) Quit (Quit: Page closed)
[21:09] <mdiggory> but at the same time, what happens when a "good change" to cleanup something like core impacts alot of those forks
[21:09] <grahamtriggs_> imho, the fact that it works better for merging (/pushing/pulling) changes around *will* help, I don't really see that the 'D' part of it makes a big difference overall (even if you wanted to make 'local saves', you could establish a local repository with git from your svn checkout (for example))
[21:09] <mdiggory> do we not improve the codesbase because it would just impact too many installations?
[21:11] <PeterDietz> I think grahamtriggs' crusade to make all the if { } bracketing line up on a new line would have impacted too many installations, but its definitely worthy of doing
[21:11] <mhwood> We announce that the contracts are changing in version X, be forewarned.
[21:12] * granitize (~Adium@137.149.66.159) Quit (Quit: Leaving.)
[21:12] <mdiggory> that where I'm happy I wrote a service based solution that didn't need to be merged with his changes...
[21:13] <mdiggory> I don't wnat to worry about merging implementations, I just want the api and the architecture to be guarunteed so I can program against it and be buffered from such activities
[21:14] <mhwood> I don't get how introducing services makes it unnecessary to ever touch any of the code again. I must be missing something.
[21:14] <mdiggory> a gross generalization... because you write your own implementation...
[21:15] <mhwood> The APIs and the architecture *are* guaranteed...until the next major version bump.
[21:15] <mdiggory> and because you rely less on common data models
[21:15] <grahamtriggs_> and somebody else writes their own implementation... and then you want an implementation that's a bit of both...
[21:16] <richardrodgers> I gotta go - many thanks, PeterDietz for your git advocacy
[21:16] <mhwood> Is this all just a fancy way of saying that we
[21:16] <mhwood> have been lax in hiding what should be internal details?
[21:16] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:16] <grahamtriggs_> I'm not arguing against services - the static 'dao' activity of the data model needs pulling out (for example)... but it's not a panacea. There will still be issues in the real world.
[21:17] <PeterDietz> so do we need to ship DSpace with org.dspace.content.CollectionInterface and content.CollectionSimpleImpl so then Mark will wire it up to use content.CollectionAtmireImpl, graham will use content.CollectionBioMedImpl
[21:17] <mdiggory> mhwood: correct
[21:17] <mdiggory> grahamtriggs_: true but I'd rather have those issues than the current ones
[21:18] <mdiggory> PeterDietz: sort of
[21:18] <mdiggory> We need to pull the CRUD off the data model so that Collection is just a bean
[21:19] <mdiggory> and place it into a SERVICE backed by the DAO
[21:19] <mhwood> And then we don't Create, Read, Update, or Delete anything anymore?
[21:19] <mdiggory> no, they are an API on the service backed by an implementation
[21:20] <kshepherd> we do.. via a collection service, not via the collection entity
[21:20] <kshepherd> i think
[21:20] <mdiggory> an implementation that is replaceable without hacking dspace-api or using classpath overriding
[21:20] <mdiggory> then... you don't need to change that core data model class anymore
[21:21] <mdiggory> or, if you do, your implementing a new interface on it
[21:23] <mdiggory> TBH.... we lost the GSoC Versioning work when we rejected the rutherford DAO branch and that was actually proving the applicability at that time... but... we all know that branch was a massive set of changes to DSpace
[21:24] <mdiggory> IN Dryad we currently have an IdentifierService that starts to replicate the work that was going on in that branch with External Identifiers. Now we are back at the point where we are considering how to implement Item Versioning... We are starting to realize that DAO work was "pivotal" and very much needed.
[21:26] <mdiggory> sorry, not to derail the Git discussion, my concern is the switch will again refocus away from these concerns
[21:26] <mhwood> Are there some examples of changes that people need to make which would be no improvement at any other site, or even harmful? In other words, that couldn't be contributed to stock and that's that, no more patching?
[21:28] <mdiggory> I have examples, but I'm not so sure thats a problem...
[21:28] <mdiggory> they just keep them to themselves right?
[21:28] <PeterDietz> umm, I can think of a local change to collection.findAll, where I did an UPPER(collection.name) to make it case insensitive sorting. So that Octopus, onCampus, Ozzy would be sorted like that
[21:28] <PeterDietz> note the lower case onCampus being between capital O
[21:29] <mhwood> Shouldn't sorting be done a bit closer to the UI?
[21:30] <PeterDietz> yeah i think so, that was a change I made in the first week of the job. However the UI's don't usually get data, they usually get formattedStuff already ready to go.
[21:34] <mdiggory> It would be great to identify two or three changes to the codebase that would get us closer to what we are seeking across 2-3 versions of DSpace.
[21:35] <mdiggory> IE pull the data access out of DSpaceObjects and deprecate the static methods
[21:35] <PeterDietz> enabling the code to be abstractable easily so that an instance does not have to hack-apart the core to make their customization
[21:36] <mdiggory> construct services that have those CRUD ops on them
[21:37] <mdiggory> move as much of the deprecated usage to the service
[21:37] <mdiggory> DSpace.getServiceManager.getService(ItemService.class);
[21:38] <mdiggory> is.update(Item i);
[21:39] <mdiggory> review JR's DAO's see if we can readopt some of that code....
[21:40] <mdiggory> http://scm.dspace.org/svn/repo/sandbox/dspace-dao-prototype/dspace-api/src/main/java/org/dspace/content/dao/
[21:40] <PeterDietz> I have a question though. When OSULibraries needs to customize findAll so that we can add case-insensitive ordering (assuming this is something that can't be done at UI level), we make our own implementation that is registered to the Collection bean. Then in our implementation, do we just implement findAll() with our customization, or do I also have to copy/paste the implementation for all the other functions in that class?
[21:41] <mhwood> So Item shouldn't be an object; it's just a structure with no behavior?
[21:42] <mdiggory> You might just inherit and override
[21:42] <mdiggory> oh golly thats novel... you mean actually use OO? Wow...
[21:43] <mdiggory> mhwood: the less behavior, the better, its called an anemic data model
[21:44] <mdiggory> ok, to bee honest,,, there are trade offs...
[21:44] <mdiggory> http://en.wikipedia.org/wiki/Anemic_Domain_Model
[21:44] <mhwood> If an object has behavior that doesn't belong there, isn't it two objects smushed together?
[21:52] <mhwood> PeterDietz: there's probably some sneaky way to get Spring to stick purple wires into Collection leading to and from YourCollection.findAll(), if you're experiencing too much performance. :-)
[21:54] <mdiggory> http://tinyurl.com/68yohb5
[21:55] <kshepherd> on a complete tangent, solr searches based on search.location:12345 are nice and easy compared to trying to build aggregations of items in java ;)
[21:55] <mdiggory> Software development is a lot like building Frankenstien’s monster. You start out with a pile of useless ugly pieces, and try to turn it into something beautiful. Along the way, it’s a monstrosity, and tends to get uglier as you tack new bits onto it. Then it kills people.
[21:56] <PeterDietz> ...and then we archive the papers of the dead people into a DSpace repository
[21:56] <mdiggory> http://foohack.com/2008/01/going-fast-frankenstein-and-refactoring/
[21:58] <mdiggory> kshepherd: ain't that the truth...
[22:01] <mdiggory> and indexing all the metadata results in a powerful mechanism for both getting a select and sorting it across whatever is put into the repo... The only place solr falls down is in capturing the data model... no JOINS or searches that span JOINS, means we have to resolve those relationships acorss multiple queries... means we still need a store that maintains such structure.
[22:01] <mdiggory> of course, solr wasn't designed for that
[22:02] <mdiggory> we still need a relational DB or some other similar tech
[22:03] * alxp (~aoneill@blk-30-155-121.eastlink.ca) Quit (Quit: alxp)
[22:05] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) Quit (Quit: Leaving.)
[22:11] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[22:14] <mhwood> It's gone quiet and I've gotta go. Parting shot: we need something like the relational *model*, but the backend could be novel.
[22:14] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[22:21] * neanlos (be90a357@gateway/web/freenode/ip.190.144.163.87) Quit (Ping timeout: 245 seconds)
[22:35] * ksclarke (~kevin@156-56-58-106.dhcp-bl.indiana.edu) has joined #duraspace
[22:35] * alxp (~aoneill@blk-30-155-121.eastlink.ca) Quit (Quit: alxp)
[22:57] * snail (~stuart@130.195.179.88) Quit (Ping timeout: 276 seconds)
[23:11] * snail (~stuart@130.195.179.88) has joined #duraspace
[23:53] * keithg (~keith-noa@207.138.47.158) Quit (Quit: keithg)
[23:56] * grahamtriggs_ (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs_)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.