Timestamps are in GMT/BST.
[5:47] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[5:47] * bradmc_ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[5:47] * bradmc_ is now known as bradmc
[6:35] -barjavel.freenode.net- *** Looking up your hostname...
[6:35] -barjavel.freenode.net- *** Checking Ident
[6:35] -barjavel.freenode.net- *** Found your hostname
[6:35] -barjavel.freenode.net- *** No Ident response
[6:35] -calvino.freenode.net- *** Looking up your hostname...
[6:35] -calvino.freenode.net- *** Checking Ident
[6:35] -calvino.freenode.net- *** Found your hostname
[6:36] -calvino.freenode.net- *** No Ident response
[6:36] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:36] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:36] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:44] -niven.freenode.net- *** Looking up your hostname...
[8:44] -niven.freenode.net- *** Checking Ident
[8:44] -niven.freenode.net- *** Found your hostname
[8:45] -niven.freenode.net- *** No Ident response
[8:45] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[8:45] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[8:45] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:54] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:58] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[19:41] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:53] * bojans (~Bojmen@62-47-250-176.adsl.highway.telekom.at) has joined #duraspace
[19:53] <tdonohue> Hi all, reminder we have our DSpace Developers Mtg here at the top of the hour. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-25
[19:53] <kompewter> [ DevMtg 2011-05-25 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-25
[19:55] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:55] * vibhajrajan (~Unnikanna@14.97.155.107) has joined #duraspace
[19:55] * cccharles (~chris@131.104.62.48) has joined #duraspace
[19:57] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) has joined #duraspace
[20:00] <tdonohue> Hey all, welcome. It's about time to get started with our DSpace Developers Mtg. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-25
[20:00] <kompewter> [ DevMtg 2011-05-25 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-25
[20:00] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> we'll begin with our usual JIRA quick review.
[20:00] <tdonohue> here's our list of issues that still need some sort of general review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-807+ORDER+BY+key+ASC
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-807 ] - [#DS-807] The selection screen of the Creative Commons don't make use the preferred language of the user - DuraSpace JIRA
[20:00] <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-807+ORDER+BY+key+ASC
[20:00] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:01] <tdonohue> we'll start today with DS-807
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-807 ] - [#DS-807] The selection screen of the Creative Commons don't make use the preferred language of the user - DuraSpace JIRA
[20:02] <mhwood> I'm not sure why we shouldn't obey the user's language setting in his browser.
[20:02] <richardrodgers> This will likely be superceded by CC rewrite - so should consider only as a pre 1.8 fix....
[20:02] <robint> Will the CC rewrite cover jspui ?
[20:02] <tdonohue> richardrodgers: is the CC rewrite work definite for 1.8?
[20:03] <richardrodgers> tdonohue: yes, we can commit, we are running locally already
[20:04] <tdonohue> ok, would be good to get a JIRA issue setup for the CC rewrite work, so that we can link this Ds-807 over to it. Also, that way we can get someone to help with JSPUI if needed
[20:04] <richardrodgers> robint: good question - the backend would work for both, but we did not hook it up to jspUI
[20:05] <richardrodgers> OK I'll open a ticket
[20:05] <tdonohue> Ds-807 Summary: should be superceded by CC Rewrite. richardrodgers will create a CC Rewrite ticket and link this over to it / close it as deemed necessary.
[20:05] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[20:05] <robint> Sounds good.
[20:06] <tdonohue> Next up, DS-810
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-810 ] - [#DS-810] Allow workflow notifications to be turned off in dspace.cfg - DuraSpace JIRA
[20:06] <mhwood> Already assigned.
[20:07] <tdonohue> ok, we'll assume kshepherd is hard at work on Ds-810, and will notify us if it needs future review
[20:07] <tdonohue> next up, DS-811
[20:07] <kompewter> [ https://jira.duraspace.org/browse/DS-811 ] - [#DS-811] Delete / withdraw items via bulk csv editing - DuraSpace JIRA
[20:07] <tdonohue> (assigned to stuartlewis looks like)
[20:08] <tdonohue> if any comments on Ds-811, please add to that issue itself. Looks like stuartlewis has this under control, and hopefully he'll let us know if it needs more review
[20:08] <richardrodgers> If Stuart is already signed up, +1
[20:08] <tdonohue> I'd say +1 to the idea as well
[20:09] <robint> +1
[20:09] <mhwood> +1 basic idea. Not so sure about overloading fields that way.
[20:10] <tdonohue> Ds-811: several in favor, leave assigned to stuartlewis for resolution. May need more discussion after stuart decides which way he'd propose to implement it
[20:10] <tdonohue> next up DS-812
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-812 ] - [#DS-812] Postgres errors - DuraSpace JIRA
[20:10] <tdonohue> grahamtriggs -- looks like you are assigned here. Anything needing review right now?
[20:11] <tdonohue> or grahamtriggs1 (not sure which is the real graham)
[20:11] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:11] <richardrodgers> none of us are
[20:12] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:12] <robint> looks like neither of them !
[20:12] <tdonohue> yep, sounds like graham isn't here. I'm assuming there *is* an issue here, since he claimed it. We'll check with grahamtriggs for updates
[20:12] <mhwood> Looks like another "run index-init". I wonder if we can conveniently detect that from the exception and tell the user what is really wrong.
[20:13] <robint> I also see this error
[20:13] <grahamtriggs1> Not sure if anything can be said without the browse.* config from dspace.cfg
[20:13] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:13] <tdonohue> Ds-812 summary: need more info from graham & others who see this issue -- need proposal for how best to resolve?
[20:13] <mhwood> Maybe at startup the app.s should take a peek and see if all of the necessary tables are in fact set up.
[20:14] <tdonohue> yea, there should be some "check", I'd think...and then a more useful error like "Your Browse Index is uninitiatlized"
[20:15] <tdonohue> ok, bring discussion to Ds-812 on best way to fix this -- would be nice to find a way to avoid this
[20:15] <tdonohue> we'll do one more for today: DS-814
[20:16] <kompewter> [ https://jira.duraspace.org/browse/DS-814 ] - [#DS-814] Missing stanza in DSpace.cfg file necessary for SOLR statistics - DuraSpace JIRA
[20:16] <mdiggory> The work we are doing on versioning checks on startup for appropriate tables and executes the appropriate sql for the db vendor to create them. I'm thinking about making install and uninstall CLI commands that will allow us to install/uninstall the db requirements.
[20:18] <mdiggory> thus installing the item versioning module would require ./dspace install-versioning-db-support for those that are more paranoid about code actually creating db objects.
[20:18] <tdonohue> any comments on Ds-814? Are these really required? They don't seem to be in 1.7.x at all (maybe they are older SOLR settings?)
[20:18] <KevinVdV> Well all I can say about it it that those properties aren't used by the DSpace stats
[20:18] <PeterDietz> I think Ds-814 is an optional way to extend solr statistics, since it functions without them.
[20:18] <mdiggory> yea thats an old ticket for something that was not part of the contribution
[20:19] <PeterDietz> so its documentation for a non-existing feature
[20:19] <tdonohue> ok, so close Ds-814 then and mark "won't fix"?
[20:19] <mdiggory> sounds like that need to go out of the docs
[20:20] <KevinVdV> Is it still in the docs?
[20:20] <mhwood> Just exported a fresh 1.6.2 and statistics.items.dc is not in there.
[20:20] <KevinVdV> I thought (not sure) that this got removed for DSpace 1.7
[20:21] <tdonohue> It doesn't look to be in the current docs.
[20:21] <mdiggory> right... its gone... close
[20:21] <mdiggory> https://wiki.duraspace.org/display/DSDOC/DSpace+Statistics
[20:21] <kompewter> [ DSpace Statistics - DSpace Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC/DSpace+Statistics
[20:21] <tdonohue> Ds-814: Close issue -- this is already resolved in docs
[20:21] <tdonohue> Ok, we'll stop there for today
[20:22] <tdonohue> Next topic: 1.7.2 updates -- what is still outstanding with 1.7.2? PeterDietz, any comments?
[20:22] <PeterDietz> For DSpace 1.7.2, we need to have DS-875 and DS-841 tested/assigned and committed into 1.7.x branch
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA
[20:22] <kompewter> [ https://jira.duraspace.org/browse/DS-841 ] - [#DS-841] 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend) - DuraSpace JIRA
[20:22] <PeterDietz> ... then I'm planning to cut on Friday
[20:23] <KevinVdV> I added some potential fixes for DS-875
[20:23] <kompewter> [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA
[20:23] <richardrodgers> Do we need an Oracle-backend tester?
[20:24] <tdonohue> richardrodgers -- we've been relying a little on hpottinger right now as they are running Oracle + DSpace 1.7 in production
[20:24] <richardrodgers> who might be here now?
[20:25] <PeterDietz> he's here, I'd like someone to test it, since it needs to be committed
[20:25] <hpottinger> I can vouch for DS-841, been running that patch for a while, it's just a rollback of a change from 1.6 to 1.7
[20:25] <kompewter> [ https://jira.duraspace.org/browse/DS-841 ] - [#DS-841] 'IllegalArgumentException: No such column rnum' error in DSpace 1.7.x XMLUI admin eperson (with Oracle backend) - DuraSpace JIRA
[20:26] <richardrodgers> thanks hpottinger !
[20:26] <tdonohue> so, based on hpottinger's 'voucher', do we want to just commit Ds-841?
[20:27] <PeterDietz> does DS-633 come into play at all (from 841's comments)
[20:27] <kompewter> [ https://jira.duraspace.org/browse/DS-633 ] - [#DS-633] NPE when deleting object returned by EPerson.findAll() - DuraSpace JIRA
[20:27] <mhwood> It shouldn't NPE anymore. At least we will get a more descriptive message.
[20:28] <PeterDietz> I'll take hpottinger's voucher that Ds-841 is suitable, and I can do the commit.
[20:28] <tdonohue> sounds good -- I'd be OK with PeterDietz going ahead and committing Ds-841, based both on the comments by hpottinger and mhwood
[20:28] <mdiggory> per Ds-841 I would say +1
[20:29] <tdonohue> now, back to DS-875. Above, I see KevinVdV said he added some new potential fixes. Anyone want to volunteer to review & hopefully commit?
[20:29] <kompewter> [ https://jira.duraspace.org/browse/DS-875 ] - [#DS-875] DSpace Configuration service error when using "dspace" script. - DuraSpace JIRA
[20:29] <robint> +1 from 1. It would be nice to confirm that the postgres stuff still works ok after commit
[20:29] <mdiggory> per Ds-875 I would also say +1 to commiting
[20:30] <KevinVdV> One of the patches involves a commit & a new release for the DSpace services
[20:30] <PeterDietz> since one of the files to patch is in services, then services will need to be released prior
[20:30] <richardrodgers> what constitues a new release, KevinVdV ?
[20:31] <tdonohue> It looks like it's this patch which needs a new release of Services -- the improvement to its logged error message if configs aren't loaded right: https://jira.duraspace.org/secure/attachment/11420/Configuration_service_log_fix.patch
[20:31] <KevinVdV> Well it may be a minor new release but we need to remove the e.printstacktrace so that the error message never appears
[20:32] <PeterDietz> new release is just whatever shipped in 1.7.1, with this one commit changed, and sub-minor version bumped and released to maven
[20:32] <mdiggory> the logging error seems samller / unrelated, we can get that into the next release, but leave current release for 1.7.2
[20:32] <mdiggory> samller = smaller
[20:32] <richardrodgers> OK thanks, just wondering about the scope of the change possibly implied by that term
[20:32] <robint> Async release in action
[20:33] <robint> Not making any comment thereon :)
[20:33] <tdonohue> So, we are doing just *one* patch in Ds-875? (the "dspace_temp_classpath_fix.patch" one?) Just making sure I understand what we just decided ;)
[20:34] <mdiggory> the two patches will be commited, but only the changes to dspace script will go into 1.7.2
[20:35] <mdiggory> we will save the logging improvement for another services release where there would be greater enhancements provided...
[20:35] <tdonohue> OK. So, 1.7.2 will include: dspace_temp_classpath_fix.patch But, the minor fix to Services will just not be released until 1.8.0
[20:35] <mdiggory> I'm sure there are more areas that logging could be improved in services
[20:36] <PeterDietz> before release i'll test that the e.printstacktrace doesn't show up in my terminal
[20:36] <tdonohue> ok, I think I understand now. Everyone else OK with this? Anyone want to volunteer to test & commit Ds-875 fix for 1.7.2?
[20:36] <KevinVdV> Feel free to test it, it should work
[20:36] <mdiggory> I just took it
[20:36] <tdonohue> ok. sounds good then.
[20:37] <tdonohue> anything else to discuss for 1.7.2? (PeterDietz, I can help with announcement if you wish -- I haven't drafted anything yet though.)
[20:37] <mdiggory> Is there a formal list of whats in there so far?
[20:38] <mdiggory> i.e. JIRA query
[20:38] <tdonohue> https://jira.duraspace.org/browse/DS/fixforversion/10464
[20:38] <kompewter> [ DSpace: 1.7.2 - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS/fixforversion/10464
[20:38] <tdonohue> it's literally just three issues we are fixing -- Ds-841, Ds-871 and Ds-875
[20:39] <tdonohue> Ok, sounds like no other updates or comments here...so, I suggest we move on to next topic
[20:40] <tdonohue> Next up is just a note that DSpace GSoC now has a weekly "Project Update" meeting immediately after this one at 21:00UTC. We'll also try and do some "quick updates" during this normal meeting each week, as a teaser for the larger meeting
[20:40] <tdonohue> But, I'd highly encourage everyone to stick around for as much of the DSpace GSoC meeting as you can (or check the IRC logs later on to see what all happened)
[20:41] <tdonohue> any other quick comments anyone wants to add about GSoC right now? (I'd like to save larger updates for 21:00UTC, if possible)
[20:42] <mdiggory> Yes, I'll comment we may want to try to get students giving a least one status update via email prior to the meeting so that we have material to preview for the week...
[20:42] <mdiggory> this was what we did in previous years.
[20:42] <vibhajrajan> ok
[20:43] <tdonohue> mdiggory, that sounds fine to me. maybe we can chat with all students / mentors about this at today's meeting?
[20:44] <tdonohue> One other Quick Note: because of the OR11 conference, we will have *no* formal IRC meetings on Weds, June 8 -- individuals or groups are welcome to show up and chat though, if you wish (and mentors are obviously encouraged to stay in touch with their students via email or IRC during that week)
[20:45] <tdonohue> Ok. moving on then for now. I've drafted up an *extremely* rough outline of our all-day face-to-face meeting before OR11. The rough outline is in today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-25
[20:45] <kompewter> [ DevMtg 2011-05-25 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-25
[20:46] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) Quit (Ping timeout: 260 seconds)
[20:46] <tdonohue> A few questions for you all: (1) I'm debating on having an "afternoon unconference" portion -- essentially a time where we can all discuss whatever topics we feel (as a group) are most pressing.. do people *like* this idea, or would you rather I scheduled things out more heavily?
[20:47] <tdonohue> (2) Just interested in any other feedback you all have -- this is your meeting too (obviously). I really don't want to be the only one thinking up topics here (and thus far, I have been) :)
[20:47] <richardrodgers> I like the flexibility, but think we should build a list of possible topics, to allow people to mull over in advance....
[20:47] <tdonohue> (that's all my questions for now -- interested in your thoughts)
[20:48] <robint> I would prefer a schedule. With potentially a big group I worry that the meeting wanders and we miss the opportunity to focus on the important stuff
[20:49] <mdiggory> I think it would be great to do, it would give us a looser structure to discuss the project roadmap / direction
[20:50] <mhwood> We do need some definite topics, but also some time into which we can push side issues that come up in other discussion..
[20:51] <tdonohue> so, a few mentioned we need "some topics". Any votes on what the "most important topics" are that we *must* discuss? I've listed a lot of possible topics which I hope we can get to -- but, I'm curious how others would rank things
[20:51] * robertqin (~robertqin@bb116-14-175-243.singnet.com.sg) has joined #duraspace
[20:51] <tdonohue> Maybe I could have each of you send me a list of your "top 5 topics you'd like to discuss"? That way, I can compile & pull together the "hot topics"?
[20:51] <tdonohue> does that sound reasonable? (realizing we don't have much time today to get deep into this)
[20:52] <robint> That sounds a good way of effectively voting
[20:52] <richardrodgers> And possibly put those into a Doodle poll or similar, so we gain consensus on what is hot?
[20:52] <tdonohue> I can also see if I can leave aside a "chunk" of time (1-2hrs) where we could even have open discussion.
[20:53] <tdonohue> richardrodgers -- perhaps -- but, I was just thinking that each person could do it free-form. I'll send everyone (who is signed up to attend) an email and ask for your "top 5" topics -- then I'll just compile them more manually
[20:54] <richardrodgers> tdonohue: no, I meant put up the assembled list, after everyone has submitted
[20:54] <robint> The more we can do in the way of preparing an agenda the more productive the meeting will be
[20:54] * hpottinger has to run, bye folks!
[20:55] <tdonohue> richardrodgers -- sure, assuming I can get everyone to respond *quickly* with their submissions, so that we can get a list up on doodle in time for people to vote
[20:55] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[20:55] <richardrodgers> tdonohue: yep, that will be the challenge
[20:56] <tdonohue> robint : I agree. I want most of the meeting to be semi-structured, but was also wanting for some flexibility as needed. I do plan to be 'strict' on keeping discussion moving along, etc.
[20:56] <mhwood> I agree that an agenda will help, but I think things will come up for which we can't prepare.
[20:56] <mdiggory> Just a comment, but the best unconferences I've attended were designed onsite in the initial hour by the attendees
[20:57] <PeterDietz> my schedule for OR week is going to be short. Due to upcoming baby, I don't want to be out of town for an entire week. So, I'll either fly in for the Monday session, or try to come in for DSUG thurs/fri.
[20:58] <tdonohue> so, you all are expressing the same questions I've been asking myself, to be honest. Hence, I had debated on having some "open" or "unconference" time (maybe not the whole meeting, but maybe a good portion of it).
[20:58] * mhwood doubts unforeseen stuff would go more than 1-2hr.
[20:58] <tdonohue> It sounds like we have two camps here -- some want more "structure", and some want "open time". I'll see if I can fit a little of both in (while realizing that I don't want to exhaust everyone by creating a 'jam packed' schedule)
[20:59] <mhwood> Well, we would benefit from structuring what we *can* structure.
[21:00] <robint> tdonohue: nothing wrong with a good compromise :)
[21:00] <mdiggory> those who want more structure can sit in the room while those that do not will reconvene at the bar across the street.
[21:00] <tdonohue> sounds good. So, I'll send a survey to everyone about your "top 5 topics" (so start thinking about them), then I'll try and schedule some/most of them. I'll also make sure to leave an "open discussion" period of 1-2hours (or so), which can be used to tackle things that come up, or things we didn't get to
[21:00] <robint> mdiggory: I'm jumping ship !
[21:01] <tdonohue> mdiggory : we already are making plans to head to the pub ~4pm or so ;)
[21:01] <mdiggory> now thats more like it!
[21:02] <mdiggory> p.s. Ds-875 Committed/Closed/resolved...
[21:02] <tdonohue> Ok. I'll leave it at that. Realizing we are now overlapping into "GSoC" time. So, we probably should close up this Devel meeting and "open" up the GSoC meeting.
[21:02] * sandsfish (~sandsfish@18.111.90.184) has joined #duraspace
[21:02] <mhwood> I have to go before the storms hit. 'bye.
[21:03] <richardrodgers> have to run, thanks all
[21:03] <mdiggory> now is not a time to be in the midwest...
[21:03] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:03] <robint> I've got to go too. Bye all
[21:03] <tdonohue> Ok. I'm not sure we really decided who would lead the GSoC meeting. My general idea here was that it'd be more "free form". Perhaps, we'd just go around and ask for general updates/questions from each Student Project
[21:04] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) Quit (Quit: Page closed)
[21:04] <tdonohue> obviously, since we are barely into GSoC, the updates right now may be minimal. But, it gives an opportunity to ask questions, or get some feedback on where to begin, etc.
[21:04] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:05] <tdonohue> Anyone else have any comments on this? mdiggory, does this seem like a good way to approach this "GSoC update meeting"?
[21:05] <mdiggory> ok, well maybe we start with an introduction for those who do not recognize the students?
[21:05] <robertqin> Hi Mark!
[21:05] <tdonohue> +1 let's do some intros... could each of the students introduce themselves & their project
[21:05] <robertqin> My name is Robert Qin
[21:05] <mdiggory> We won't have everyone due to time zones
[21:05] <robertqin> a 3rd year information system student from Singapore
[21:06] <robertqin> working on the webmvc project
[21:06] <robertqin> its great to be here
[21:06] <PeterDietz> Hi robertqin
[21:06] <tdonohue> mdiggory : yea, I realize that -- was more stating that for any students who are here :)
[21:06] <vibhajrajan> I am Vibhaj Rajan from India working on the project DSpace ClientUI built on REST API
[21:06] <tdonohue> Hi robertqin! welcome!
[21:06] <vibhajrajan> I am doing 3rd year Computer Science and Engineering at IT BHU India
[21:06] <robertqin> thanks Tim !
[21:07] <mdiggory> Hello Robert, hello Vibhaj
[21:07] <bojans> Hi Robert and Vibhaj
[21:07] <vibhajrajan> Very happy to contribute to DSpace and GSoC
[21:07] <robertqin> Same here :)
[21:07] <tdonohue> Hi vibhajrajan! Also, welcome to you!
[21:07] <vibhajrajan> thanks all
[21:07] <mdiggory> So I think that sets the stage for discussing webMVC and REST and some of the topics that came up in the last week?
[21:08] <tdonohue> go for it, mdiggory
[21:09] <mdiggory> Well I think we concluded fromt he dialog that it'd be wise that even though we see alignment in technology, to operate any server side Spring related work independently so as to keep the two projects operating efficiently?
[21:10] <mdiggory> There appears to be some popular opinion that Spring is the way to go for the final REST implementation, but that some think it will take time to play out, possibly longer than we have for a release schedule?
[21:10] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[21:10] <tdonohue> Yea, that's the same understanding I had. I also wanted to note the concerns that robint (who had to leave already) and I had about changing REST entirely to Spring before DSpace 1.8. It sounds like bojans also felt that may be too difficult to do.
[21:11] <bojans> Yes as I have expressed in email, I am not sure if it can be done completely for the next release, at least based on previous exerience
[21:12] <tdonohue> yea, I'd agree bojans. It seems like a lot of work -- and we also wouldn't want to accidentally disrupt vibhajrajan's project
[21:12] <bojans> For instance, there are also some issues related to DSpace API which will reflect both implementations, no mater Spring or EB
[21:12] <grahamtriggs1> Although there are a few tricksy bits in the MVC / Freemarker project to do interesting things with the Freemarker layer, there isn't really any great mystery / magic in the way the MVC is set up - we're just talking about Spring loading some config and a DispatcherServlet to pass off to the Controllers.
[21:13] <bojans> For instance, from current perspective it may seem as a something which can be done in relatively short time
[21:13] <bojans> but from the other side it usually takes more
[21:14] <grahamtriggs1> So REST can edge towards using MVC itself as it sees fit, without really worrying about what MVC / Freemarker is up to. Meshing the two things later shouldn't be that troublesome.
[21:14] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Read error: Connection reset by peer)
[21:16] <tdonohue> ok, so it sounds like we have some general agreement here then
[21:16] <mdiggory> I'm not particularly convinced it would be a difficult switch, mostly because as bojans suggests, theres already considerable business logic worked out, I wonder mostly about the authorization stack involvement with spring rest, thats about it... but we can look at webmvc and get ideas from there as well.
[21:17] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[21:17] <mdiggory> But I do agree that the JAvascript UI project should be able to start on the current version and then switch to a new version as it matures, as long as the REST API exposed stays consistent
[21:18] <mdiggory> I'm mostly interested in seeing the transition to Spring because of the capability to extend the REST webapp with Maven overlays will be very clean and succinct.
[21:18] <vibhajrajan> yes consistent REST interface shall allow easy switch when necessary
[21:19] <mdiggory> and we can release it without concern for thirdparty jars from non-maven central projects
[21:19] <tdonohue> mdiggory -- I just worry REST be *more likely* to be delayed past 1.8 if we try to switch REST API to Spring immediately. Unless we have several people dedicated to moving it to Spring, it seems like there's too much chance it wouldn't get done before the first 1.8 release candidate.
[21:19] <mdiggory> which will allow for shipping it withint he dspace release
[21:20] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[21:20] <mdiggory> so, my response that was coming in the email is... I'm not sure why we aren't letting it play out and instead cautioning not to work on it?
[21:20] <tdonohue> mdiggory -- I think we're also going on a slight tangent here. Although REST API work affects GSoC, none of these GSoC projects have a goal of switching REST API to Spring :) So, we may want to turn this back around to GSoC
[21:21] <mdiggory> quite true... and perhaps best for the email thread...
[21:21] <vibhajrajan> I would like to know about the javascript framework to be used, considering licensing issues as I had asked on my previous mails
[21:21] <mdiggory> the point is that for the GSoC projects, you should rely on the existing REST app as your template for the initial featureset of your UI
[21:22] <mdiggory> regardless of the debates that may go on in the community about ultimate implementation of the rest solution.
[21:22] <tdonohue> +1 all GSoC projects should work with the existing REST app
[21:23] <tdonohue> vibhajrajan -- good question. (i'm going back and checking my email -- I'm forgetting which javascript frameworks had which licenses)
[21:23] <vibhajrajan> Ext JS - GPLv3
[21:23] <mdiggory> So, I will come back the the javascript UI and suggest that I have an interest in seeing how javascript UI's can be applied not just in your project, but in the existing xmlui and webmvc projects
[21:23] <vibhajrajan> Dojo MIT
[21:23] <vibhajrajan> JxLib MIT
[21:23] <vibhajrajan> UIZE BSD
[21:23] <vibhajrajan> MochaUI MIT
[21:24] * sandsfish (~sandsfish@18.111.90.184) has left #duraspace
[21:24] <tdonohue> Ok, I know the MIT & BSD licenses are compatible with DSpace's licenses. However, I think there are issues (which mdiggory pointed out in email) with GPLv3.
[21:25] <vibhajrajan> so i must try out with the frameworks other than Ext JS
[21:25] <mdiggory> I wasn't convinced it was GPLv3 so much as its interpretation by the company that is making Ext JS opensource.
[21:26] <mdiggory> I think it is lame that we have to be cautious of such things.
[21:26] <bojans> there is also possible issue (which has been mentioned during initial proposal phase) related with further maintenance and future of chosen framework
[21:27] <vibhajrajan> mdiggory -- the restclient is based on another javascript project of mine serviceclient which would allow easy use of javascript developed for restcient in the other webapps
[21:27] <mdiggory> because it excludes perfectly good code solutions for being used...
[21:27] <grahamtriggs1> It might be a bit different in the case of a 'javascript UI over REST', but tbh, for making Javascript enhancements to xmlui / jsp / freemarker, I wouldn't really want to look anywhere other than jQuery
[21:27] <vibhajrajan> right i would switch to Dojo or JxLib then
[21:28] <mdiggory> bojans: correct, the choice has to do both with OS licensing and with the viability of the third party project going forward.
[21:28] <vibhajrajan> yes jQuery would be great given its community support
[21:28] <mdiggory> Dojo is actually another GSoC org
[21:30] <mdiggory> for xmlui, we've invested in consolidating js library usage on JQuery
[21:30] <tdonohue> jQuery does have a lot of support in the DSpace community
[21:30] <vibhajrajan> i prefered Ext JS and then Dojo due to their look and feel
[21:31] <vibhajrajan> the other frameworks are fast though since they are based on mootools
[21:32] * grahamtriggs2 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[21:32] <mdiggory> I would say that dojo seems more like an OS community whereas ExtJS seems like a proprietary project under a GPL license.
[21:33] <tdonohue> How does http://jqueryui.com/ compare into all of this? Would we want to consider JQueryUI over REST, or is that more difficult than Ext JS or Dojo? (I'm actually not as knowledgeable in this area, to be honest)
[21:33] <kompewter> [ jQuery UI - Home ] - http://jqueryui.com/
[21:34] <mdiggory> Note, my comments are not specific to liking or knowing Dojo, just observation
[21:34] <vibhajrajan> yes that too is an option to investigate
[21:35] <mdiggory> I think whatever is chosen should provide for jquery use as well to some degree.
[21:35] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Ping timeout: 246 seconds)
[21:35] <vibhajrajan> i found jQuery providing lesser ui widgets than Ext JS or Dojo
[21:35] <bojans> i am not sure about jquery, is it (alone) enough, there is smaller set of ui elements suported
[21:36] <mdiggory> http://tech.yes-co.nl/2009/08/25/jquery-versus-dojo-versus-yui/
[21:36] <kompewter> [ JQuery versus Dojo versus YUI « Tech blog ] - http://tech.yes-co.nl/2009/08/25/jquery-versus-dojo-versus-yui/
[21:36] <vibhajrajan> though we do have the option of using client side html templates and css styling to provide good look and feel
[21:36] <mdiggory> http://www.jquery4u.com/articles/jquery-dojo/
[21:36] <vibhajrajan> this way it would be quite fast
[21:36] <kompewter> [ jQuery is better than DOJO! (10 Reasons) | jQuery4u ] - http://www.jquery4u.com/articles/jquery-dojo/
[21:37] <mdiggory> [vibhajrajan: using client side html templates and css styling to provide good look and feel ] <--- sounds important
[21:37] <bojans> about speed: i do not think it would be an issue, usually the pages there are not expected to be rich in elements
[21:39] <bojans> also for the speed, based on comparison link provided by mdiggory, dojo and jquery are on the same level
[21:40] <vibhajrajan> regarding the template usage this would allow easy customization of look and feel
[21:40] <tdonohue> I'll admit, it might be good to investigate using jQueryUI, just because DSpace already uses jQuery in other areas... So, it might be a good way to ensure the Javascript UI over REST is more 'immediately' accepted, etc
[21:40] <vibhajrajan> yes and as mentioned Dojo has rather poor documentation too
[21:41] * mdiggory cautions speed comparisons will always be biased towards those who made the comparison... ;-)
[21:41] <bojans> for the selection of the template i suppose we want first to identify important points for selection
[21:41] <bojans> for instance:
[21:42] <bojans> 1) licencing - already discussed
[21:42] <bojans> 2) viability - community support - adoption - maintenance
[21:42] <bojans> 3) ui capability - what it offers us, as we want to have nice l&f
[21:42] <bojans> 4) speed and documentation
[21:42] <mdiggory> 5) ease in supporting developing AJAX
[21:43] <bojans> 5) extendability, support, debugging
[21:43] <bojans> these are some of the points
[21:43] <bojans> maybe we could take 2-3 frameworks
[21:43] <bojans> and based on such selection/rating select one
[21:44] <tdonohue> sure, bojans, that sounds like a good way to analyze, rate and select amongst Javascript UI frameworks
[21:44] <bojans> because for me, the idea behind this project (when i proposed it) is to get user interface which would be apealing and which would introduce not just better look and feel but also usability and other options
[21:44] <bojans> but of course, there are also other factors which may affect it or be other way overseen by me
[21:44] <mdiggory> this would be a wise task to assure our choice is optimal. We might also consider creating some sort of poll so that the larger community can provide anonymous ratings as well.
[21:44] <vibhajrajan> i agree that these issues are involved but i was thinking about compiled client side templates ... they are just like freemarker templates but on client side
[21:45] <vibhajrajan> http://code.google.com/p/embeddedjavascript/wiki/Templates
[21:45] <kompewter> [ Templates - embeddedjavascript - How to use templates with EJS. - EJS Embedded JavaScript Framework - Google Project Hosting ] - http://code.google.com/p/embeddedjavascript/wiki/Templates
[21:46] <vibhajrajan> such templates are built in within Ext JS and UIZE, for others we may design our own using embedded JS
[21:46] <vibhajrajan> these allow the templates to be renderd on clint with data fetched by JSON from server (in our case REST service)
[21:47] <tdonohue> hmm... i actually wasn't familiar with compiled client side templates (Learn something new every day!)
[21:48] <tdonohue> It looks like there's also a jQuery option (not sure if it's as good as Ext JS, etc.) : http://blog.reybango.com/2010/07/09/not-using-jquery-javascript-templates-youre-really-missing-out/
[21:48] <bojans> ok that sounds interesant
[21:48] <kompewter> [ Not Using jQuery JavaScript Templates? You’re Really Missing Out. - Rey Bango ] - http://blog.reybango.com/2010/07/09/not-using-jquery-javascript-templates-youre-really-missing-out/
[21:48] <vibhajrajan> i too learnt them when working in Ext JS recently
[21:49] <mdiggory> JQuery analog: http://api.jquery.com/category/plugins/templates/
[21:49] <kompewter> [ Templates – jQuery API ] - http://api.jquery.com/category/plugins/templates/
[21:49] <vibhajrajan> jQuery's support for templates would be quite good to consider the framework for restclient
[21:51] <vibhajrajan> so i'll consider jQueryUI as primary option and then investigate JxLib and others
[21:51] <bojans> ok it seems this support is in beta, but for me sounds reasonable
[21:52] <vibhajrajan> right then thanks all for the long discussion
[21:52] <tdonohue> it sounds reasonable to me as well.
[21:52] <mdiggory> I suspect there'll be other template projects/options in the JQuery sphere
[21:53] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[21:53] <mdiggory> http://wiki.jqueryui.com/w/page/37898666/Template
[21:53] <kompewter> [ jQuery UI Development & Planning Wiki / Template ] - http://wiki.jqueryui.com/w/page/37898666/Template
[21:53] <bojans> ok i suppose it is 3 am now there in india :)
[21:54] <vibhajrajan> right 3:30 am :)
[21:54] <mdiggory> Ah, the life of A GSoC student ;-)
[21:54] <vibhajrajan> i am quite happy to attend this meeting and talking to all there :)
[21:54] <tdonohue> wow. thanks for joining us at so early (or late) an hour :)
[21:55] <vibhajrajan> i'll try to every week :)
[21:55] <mdiggory> yes, but we will understand if you miss one :-)
[21:56] <vibhajrajan> thanks ok then bye :) will catch the rest of discussion in logs
[21:56] <bojans> ok good night and bye :)
[21:56] <tdonohue> definitely -- it's not expected that everyone will make this meeting -- but, if you don't, just send us some brief email updates :)
[21:56] <vibhajrajan> right
[21:56] <mdiggory> hmmm... one last link...
[21:56] <mdiggory> http://www.bennadel.com/blog/2026-jQuery-Template-Markup-Langauge-JTML-vs-jQuery-Templates.htm
[21:56] <kompewter> [ jQuery Template Markup Langauge (JTML) vs. jQuery Templates ] - http://www.bennadel.com/blog/2026-jQuery-Template-Markup-Langauge-JTML-vs-jQuery-Templates.htm
[21:57] <mdiggory> and http://blog.jquery.com/2010/10/04/new-official-jquery-plugins-provide-templating-data-linking-and-globalization/
[21:57] <kompewter> [ jQuery: » New Official jQuery Plugins Provide Templating, Data Linking and Globalization ] - http://blog.jquery.com/2010/10/04/new-official-jquery-plugins-provide-templating-data-linking-and-globalization/
[21:57] <vibhajrajan> this is great .. noted that
[21:57] <mdiggory> a Microsoft contribution to JQuery....
[21:57] <mdiggory> In March, we announced at MIX 2010 that Microsoft had committed to supporting the jQuery Project via code contributions and resources. Shortly thereafter, Microsoft made available for public review their first jQuery plugin which provided client-side templating capabilities to the jQuery community.
[21:58] <tdonohue> I've got to go, unfortunately. But, it's been good discussion, and nice to see both vibhajrajan and robertqin here. (if you all have more to discuss without me, feel free...I just have to leave as there are large thunderstorms now in the area, and I should get offline)
[21:58] <mdiggory> Today, we’re very happy to announce that the following Microsoft-contributed plugins – the jQuery Templates plugin, the jQuery Data Link plugin, and the jQuery Globalization plugin – have been accepted as officially supported plugins of the jQuery project. As supported plugins, the jQuery community can feel confident that the plugins will continue to be enhanced and compatible with future versions of the jQuery and jQuery UI
[21:58] <mdiggory> libraries.
[21:59] <mdiggory> tdonohue: be safe
[21:59] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[21:59] * vibhajrajan (~Unnikanna@14.97.155.107) has left #duraspace
[22:16] * robertqin (~robertqin@bb116-14-175-243.singnet.com.sg) has left #duraspace
[22:44] * grahamtriggs2 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving.)
[22:48] * bojans (~Bojmen@62-47-250-176.adsl.highway.telekom.at) Quit (Remote host closed the connection)
[23:02] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.