Timestamps are in GMT/BST.
[0:17] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[0:17] * mdiggory (n=mdiggory@76.176.188.83) Quit (Read error: 131 (Connection reset by peer))
[0:17] * mdiggory_ is now known as mdiggory
[0:18] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Connection reset by peer)
[0:18] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[0:18] * mdiggory_ is now known as mdiggory
[2:18] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
[2:18] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[2:19] * mdiggory_ is now known as mdiggory
[2:19] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
[2:19] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[2:19] * mdiggory_ is now known as mdiggory
[2:20] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Connection reset by peer)
[2:20] * mdiggory_ (n=mdiggory@76.176.188.83) has joined #duraspace
[2:20] * mdiggory_ is now known as mdiggory
[2:20] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[2:20] * mdiggory (n=mdiggory@76.176.188.83) Quit (Read error: 131 (Connection reset by peer))
[2:21] * mdiggory_ is now known as mdiggory
[2:34] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has left #duraspace
[4:05] [freenode-connect VERSION]
[4:05] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:05] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:05] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[5:08] * grahamtriggs (n=trig01@195.128.10.96) has joined #duraspace
[6:45] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (hubbard.freenode.net irc.freenode.net)
[6:45] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) Quit (hubbard.freenode.net irc.freenode.net)
[6:45] * ChanServ (ChanServ@services.) Quit (hubbard.freenode.net irc.freenode.net)
[6:45] * grahamtriggs (n=trig01@195.128.10.96) Quit (hubbard.freenode.net irc.freenode.net)
[6:45] * krnl__ (i=krnl_@193.219.158.144) Quit (hubbard.freenode.net irc.freenode.net)
[6:45] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) Quit (hubbard.freenode.net irc.freenode.net)
[6:47] * ChanServ (ChanServ@services.) has joined #duraspace
[6:47] * grahamtriggs (n=trig01@195.128.10.96) has joined #duraspace
[6:47] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[6:47] * kshepherd (i=kim@ec2-174-129-179-33.compute-1.amazonaws.com) has joined #duraspace
[6:47] * krnl__ (i=krnl_@193.219.158.144) has joined #duraspace
[6:47] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[6:49] [freenode-connect VERSION]
[8:09] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:15] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (hubbard.freenode.net irc.freenode.net)
[9:16] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) has joined #duraspace
[9:22] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[10:49] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) has joined #duraspace
[11:29] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[11:54] * tdonohue (i=80ae241d@gateway/web/freenode/x-qgsenczwyrgwryds) has joined #duraspace
[11:59] * cwilper (i=4a2c9b5a@gateway/web/freenode/x-zwnmikeirxehfihg) has joined #duraspace
[11:59] * pketienne (n=petienne@lib-petienne.library.gatech.edu) has joined #duraspace
[11:59] * pketienne (n=petienne@lib-petienne.library.gatech.edu) has left #duraspace
[12:04] <bradmc> Hi folks. We are scheduled for a DSpace committer's meeting now, but several have indicated that 4 hours from now is their only possibility today.
[12:05] <bradmc> That reinforces a trend towards just the later time, which will likely become the default unless we hear screaming from Europe :)
[12:06] * rrodgers (n=rrodgers@dhcp-18-111-24-120.dyn.mit.edu) has joined #duraspace
[12:09] <rrodgers> Hello - DSpace commiter IRC now?
[12:10] <bradmc> Would be, except almost everyone has bailed until 4:00. So I think this is the death knell for the early version of the meeting.
[12:10] <rrodgers> Seems like it
[12:10] <rrodgers> Do we have business at 4:00?
[12:11] <bradmc> I'd assume there will be a little last minute 1.6 and DSUG coordination.
[12:11] <rrodgers> K - I'll check back Thanks bradmc
[12:11] <bradmc> Probably won't be a good time for an issues review, as I doubt much focus.
[12:12] * rrodgers (n=rrodgers@dhcp-18-111-24-120.dyn.mit.edu) Quit ()
[12:12] * cwilper (i=4a2c9b5a@gateway/web/freenode/x-zwnmikeirxehfihg) Quit ("Page closed")
[12:17] * tdonohue (i=80ae241d@gateway/web/freenode/x-qgsenczwyrgwryds) Quit ("Page closed")
[12:49] * grahamtriggs (n=trig01@195.128.10.96) has left #duraspace
[13:23] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
[13:23] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[13:23] * mdiggory_ is now known as mdiggory
[13:31] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[13:31] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has left #duraspace
[13:41] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:41] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace
[15:48] * lcs (n=lcs@serenity.hul.harvard.edu) has joined #duraspace
[15:49] * lcs (n=lcs@serenity.hul.harvard.edu) has left #duraspace
[15:49] * lcs (n=lcs@serenity.hul.harvard.edu) has joined #duraspace
[16:00] <bradmc> Anybody around for a brief committer's Mtg?
[16:00] * stuartlewis puts his hand up
[16:01] <bradmc> I suspect that a Jira review today won't fly, so we'll defer that for two weeks unless I hear objections.
[16:01] <lcs> i'm here
[16:01] * kshepherd is semi-here, just trying to fix some stuff for Otago
[16:01] <mhwood> Present!
[16:01] <bradmc> Topics of interest? I assume 1.6, and DSUG, what else?
[16:02] <lcs> i wanted to ask why SR/W hasn't been adopted into the codebase
[16:02] <grahamtriggs> Who is for having a committer meeting next week at the same time, in a bar in Sweden?
[16:03] <stuartlewis> lcs: AFAIK no one has really pushed for it to be included.
[16:03] <bradmc> grahamtriggs: I'm for having a committer meeting next week in a bar, wed evening.
[16:04] <stuartlewis> Which night is conference dinner?
[16:04] <bradmc> lcs: I don't know of any specific reasons.
[16:05] <bradmc> stuartlewis: 15th, second night (thu)
[16:05] * tdonohue (i=80ae241d@gateway/web/freenode/x-cdmryswgtaxluxel) has joined #duraspace
[16:05] <stuartlewis> Meeting web night sounds great then :)
[16:05] <bradmc> 14th, poster session ends 7pm, so committers meal / meeting / drinks is possible.
[16:05] <stuartlewis> If we hold it at about 9pm, I'll just be waking up :)
[16:06] <kshepherd> lcs: srw might be another good way of showing people how easy it is to work with dspace modules these days.. (assuming it's as easy as a quick pom edit to include in a maven build) but i would also be happy to see it in core
[16:06] <kshepherd> well i hope you all have a few drinks for me ;P
[16:06] <mhwood> I think we are at a point where it would be good to try to keep things out of core unless they have to go in.
[16:06] <stuartlewis> When is everyone turning up? Anyone for a dinner / drink on Tues night?
[16:07] <bradmc> I am, yes.
[16:07] <lcs> OK, I'll see about looking into it.. lots of sites would probably use it if it were just available.
[16:07] <bradmc> lcs: thanks!
[16:07] <grahamtriggs> yes, I'll be around Tuesday
[16:07] <kshepherd> lcs: i suspect that too
[16:07] <mhwood> Yes, thanks lcs.
[16:07] <grahamtriggs> SRW... didn't MacKenzie have something to say about it on the lists a while ago?
[16:07] <stuartlewis> I'll post a note on the crowdvine, and we can arrange something from there?
[16:07] <bradmc> That works for me.
[16:09] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[16:09] <stuartlewis> Hi Mark
[16:09] <mdiggory> Have I missed much?
[16:09] <stuartlewis> Just discussing inclusion of SRU/W in DSpace via a module
[16:09] <bradmc> mdiggory: DSUG casual committer's getogether Tue eve - check crowdvine; Wed eve committer's dinner / mtg after poster session.
[16:10] <tdonohue> i'm just catching up as well...hi all
[16:10] <stuartlewis> Hi TIm
[16:10] <mhwood> Interest in adopting SRU/W
[16:11] <bradmc> lcs looking into how to adopt SRU/W; some preference for as a module.
[16:11] <mdiggory> mhwood: theres two source trees atm... one in modules.... dspace-srw... one which Ralph Levien is maintaing on Google code
[16:11] <grahamtriggs> hmm... just found one message from MacKenzie that suggests a licensing issue (GPL)
[16:11] <mdiggory> no...
[16:12] <mdiggory> the one in modules dir removes all GLP related stuff....
[16:12] <lcs> IIRC their licensing changed so it's resolved now.
[16:12] <mdiggory> there was a dependency that was GPL... not that I care
[16:13] <mdiggory> whats more important is dealing with management of the DSpace SRW driver code being maintained in both places atm
[16:14] <stuartlewis> Do you think Ralph would be happy maintaining it our scm too?
[16:14] <stuartlewis> s/it our/it in our/
[16:14] <mdiggory> I originally invited Ralph to maintain this in dspace-sandbox. He opted to maintaining in a more "all encompassing" space
[16:14] <stuartlewis> How often does it change?
[16:16] <mdiggory> you'll have to check with him on that...
[16:16] <mhwood> Good example for out-of-tree modules? What would it need to have a nice stable place to plug into DSpace?
[16:17] <mdiggory> no what is needed is release processes that put it into the maven central repo
[16:17] <mdiggory> so that we could just grab it
[16:17] <lcs> looks like he's been maintaining it on google code periodically, last change in june this year.
[16:17] <mdiggory> true... I have some topics I feel need addressing in the meeting above/beyond this... for the release
[16:18] <stuartlewis> Presumably if we include it as a module, we can ignore it for now while we're busy getting 1.6 out the door, then get it all sorted by Christmas, and show advertise how to enable it via pom tweaking?
[16:18] <mdiggory> sorry, I wasn't referring to srw/u
[16:19] <bradmc> stuartlewis: That seems sensible.
[16:19] <mdiggory> one can easily create an modules/srw/pom.xml and include it themselves
[16:19] <lcs> stuartlewis: that would be fine so long as there's a documented procedure
[16:19] <bradmc> Are we almost ready to move to 1.6 discussion? Mdiggory is already there ...
[16:19] <stuartlewis> Yes - 1.6 :)
[16:19] <mhwood> OK
[16:20] <stuartlewis> mdiggory: How are stats going? I saw lots of cool committs overnight
[16:21] <mdiggory> sorry, multiple chats...
[16:22] <mdiggory> yes, stats are in progress. we have testing and debugging of the dspace-xmlui-stats package in the modules directory that needs doing on the @mire side
[16:22] <mdiggory> the dspace-solr and dspace-services integration is in place and functioning
[16:22] <stuartlewis> Anything we can do to help out?
[16:23] <stuartlewis> When do you reckon it might be ready for us to play with?
[16:23] <mdiggory> not until there is debugging done on my end with the stats.
[16:24] * mdiggory why's he keep asking me that ;-)
[16:24] <mdiggory> I'm hoping the end of the week
[16:24] <mdiggory> but my presentation pre is suffering for it
[16:24] <mdiggory> pre = prep
[16:25] <stuartlewis> Excellent :)
[16:25] <mdiggory> mostly, the dspace-services stuff... it would be good to those working on the trunk and testing it to make sure they don't encounter startup issues
[16:26] <mdiggory> the stats engine stuff is not plugged in yet, so all that is in place is a LoggingUsageEventListener
[16:26] <mdiggory> that write log entries for usage events
[16:27] <mdiggory> this should be coming out in the logs when you view DSO's
[16:27] <stuartlewis> They worked OK for me when I tried :)
[16:27] <stuartlewis> And I see messages about things like the user sessions being killed etc in catalina.out
[16:28] <stuartlewis> OK - any other outstanding features for 1.6, or can we have the feature freeze now (except for the stats)?
[16:28] <mdiggory> My other concern
[16:28] <mdiggory> is with recent work in the trunk... I noticed that at the same time lcs was merging in his work on authority control.
[16:28] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 54 (Connection reset by peer))
[16:28] <lcs> i'm still tinkering with DS-285, hope to have that done today or tomorrow
[16:29] <mdiggory> I'm not comfortable with the shared ui overlay
[16:29] <stuartlewis> lcs: OK. Thanks.
[16:29] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:29] <lcs> the shared ui stuff is not an overlay, it's just basic project includes like everything else uess
[16:30] <mdiggory> if its a war pom added as a dependency to another war pom.... its an overlay
[16:31] <mdiggory> In this case there are a couple arguments I have for why I don;t want to promote this practice here.
[16:31] <lcs> it doesn't use the overlay mechanism explicitly. does maven make it an overlay behind the scenes? tell me another way to accomplish the same sharing, then.
[16:32] <mdiggory> yes, it does use the maven overlay mechanism explicity
[16:32] <mdiggory> or maybe better quialified as "implicitly
[16:32] <mdiggory> simply by creating the dependency
[16:33] <mdiggory> my concern is the following. (1) it would be best to limit overlaying to the modules or addons outside the core distribution, more overlays mean more compile time
[16:34] <mdiggory> (2) overlays need to have a specific order of application and if that is shuffled the resulting product will different than expected, thus its best to limit using them
[16:34] <mdiggory> to customization
[16:35] <mdiggory> 3.) Overlays don't work wewll in Eclipse m2eclipse and some other IDE's or introduce intensive amounts of file copying when used as a dependency to the project your working on
[16:35] <lcs> perhaps we should take this offline. there has to be another way to share a sub-project between UIs.
[16:36] <mdiggory> Its a good topic to try to resolve in a meeting
[16:36] <lcs> it's unacceptable to make two copies of crucial source files and expect people to keep them in sync manuall just because the tools are weak
[16:37] <mdiggory> well thers one more argument I have that has little to do with tools.
[16:38] <mdiggory> This maven project only has 5 javascript files in it
[16:38] <mdiggory> I assume a majority of them are unchanged from the original library?
[16:38] <lcs> there are crucial bugfixes to the original scriptaculous code.
[16:38] <mdiggory> sorry, I did not complete a thought there...
[16:39] <lcs> if the shared JS is moved to dspace-api, could the maven assembly stuff put it in the right place in the generated WARs for UIs?
[16:40] <mdiggory> I'm concerned about introducing a bridge in the dependencies of jspui and xmlui just for some supporting presentation javascrpt files
[16:40] <mdiggory> that introduces more complexty to the build process than the overlay mechanism itself
[16:41] <mdiggory> sorry, lcs, refering to moving it to dspace-api
[16:41] <lcs> there is also a file of utility JS shared between UIs too since it uses the common choice AJAX pproduction.
[16:42] <mdiggory> thats just javascript you wrote for the forms?
[16:44] <lcs> i'm open to any solution that does not involve replicating all the common JS in two places. The JS I wrote is for forms and submission UI elements. think of it as in the same zone as the configurable submission UI.
[16:45] <stuartlewis> Is there any harm in leaving it in for now, then post 1.6 we can see if there is a better strategy?
[16:45] <mdiggory> The overarching issue here is the continued cost of maintaining two separate UI in parity... IMO, we have reached the point where this has to cease. Not only is it exhaustive to our development resources, it also introduces added complexity to maintaing the codebase.
[16:46] <lcs> i went to some effort to share the JS to *reduce* the complexity of maintaining two UIs.
[16:46] <mdiggory> stuartlewis: the problem with releasing it... is that once you have... you have to maintain it and/or provide an exit strategy from it if you no longer want to
[16:46] <mdiggory> lcs: its a trade off, your just trading one kind of complexity for another
[16:47] <mdiggory> instead of the developers maintaining the exception in this case... its pushed off to the end user compiling and installing dspace..
[16:48] <mdiggory> as a time cost for the additional overlay on two different UI wars
[16:48] <stuartlewis> So is the safer approach to make two copies for now, and we'll address it later? (with the solution perhaps even being that a UI gets dropped in a future release sometime)
[16:48] <mdiggory> and having to figure out where the files are coming form if they wish to customize or change them
[16:48] <lcs> it's less safe to make two copies of the code.
[16:48] * stuartlewis doesn't know enough about maven to join in the discussion, and by the silence of most other people, I suspect the same is true with them?
[16:49] <mhwood> I begin to understand, but not yet enough to speak.
[16:49] <lcs> the trail of dependencies is as clear as anything in maven.
[16:50] <mdiggory> lcs, I understand where your coming from. but IMO its not enough of a concern in the face of creating greater build complexity.
[16:50] <lcs> compile-time cost doesn't affect most end users very much; how often do they spend compiling vs. figuring out why maven is screwing htem?
[16:50] <grahamtriggs> who is this 'end user' that is compiling and installing dspace? surely it is, or should be, in most cases a developer of some form. I worry that we look to take on too many complexities within the codebase, and raise the barrier for anyone that wants to go further than merely installation and configuration
[16:51] <mhwood> Time != complexity.
[16:51] <mdiggory> grahamtriggs: its all of us developers and our users doing installation/customization
[16:51] <stuartlewis> The meeting needs to wind up in 10 minutes... should we offline this discussion (or postpone it until after the meeting)?
[16:52] <bradmc> Actually, mdiggory is correct that it's a trade off. But two copies smells really bad, and removing XMLUI this afternoon seems a little extreme (*).
[16:52] <mhwood> Are there other topics?
[16:52] <mdiggory> bradmc: removing XMLUI?
[16:52] <lcs> i had one other unpopular suggestion, going back to DS-297
[16:52] <mhwood> Remmoving JSPUI, you mean. :-)
[16:52] <bradmc> (*) I knew I get attention with that.
[16:53] * mdiggory ducks objection from grahamtriggs
[16:53] <lcs> i'd like to try moving all PostgreSQL-specific files to a postgres subdirectory, like the oracle subdirectory.
[16:53] <bradmc> Removing either right this second seems rash. And we haven't proposed anything that lets lcs proceed.
[16:54] <stuartlewis> DS-297 - no objection from me.
[16:54] <mdiggory> Thats like swatting a fly with a bazzoka
[16:54] <lcs> re Uis, well, i have already checked in the code that uses a shared war project.. not knowing it secretly uses the Evil Overlay
[16:54] <mdiggory> refering to removing JSPUI to solve a small amount of code duplication
[16:54] <grahamtriggs> there won't just be objections from me. I get the feeling that there a few firmly anti-XMLUI (although I'm not anti-XMLUI per se, just can't deal with it's footprint) - possibly as many as a very pro-XMLUI. The rest just drift with the flow :)
[16:55] <lcs> we did promise to maintain UI parity in 1.6, though.
[16:55] <mdiggory> lcs: thats why I brought it up
[16:55] <mdiggory> true
[16:55] <bradmc> So let's deal with the flow next week, better done then. We can try again to forge a new direction.
[16:55] <grahamtriggs> mdiggory: I pity the bugs in your house. And your house.
[16:55] * stuartlewis is lost - what are we discussing now?
[16:56] <mdiggory> I'm not suggesting stopping the practice for 1.6, just maybe after
[16:56] <mdiggory> Seems we are trying to moe onto DS-297
[16:57] <mdiggory> lcs, I think theres got to be a better solution for the SQL in the future that will properly associate it with the code that uses it...
[16:57] <mdiggory> but I'm of the opinion that in the etc directory, the build process shouldn't be "moving files around.
[16:57] <stuartlewis> DS-297: I'm happy to make a change, but at the same time, if it ain't broke.... no one runs in any problems with it.
[16:58] <mhwood> Something I've wondered about: how much pain would it cause to take *all* the brand-specificisms out of the database code? We have standards for a reason.
[16:58] <lcs> mdiggory: but that future is well beyond 1.6.x, so for now we have to live with it
[16:58] <mdiggory> so, I assume that if they are in a postgres directory in the source tree, after the installation the will be in a ${dspace.dir}/etc/postgres directory
[16:58] <mdiggory> ?
[16:59] <lcs> mhwood: unfortunately between sequences, large strings (for metadata values), and constraints we're well out of the range of "standard" SQL
[16:59] <grahamtriggs> mhwood: simple answer is that we have to rely on things that either aren't covered by standards, or the implementations don't quite follow the standards
[16:59] <lcs> yes, that's the idea, re postgres subdirectory
[16:59] <mdiggory> mhwood: we rely on experts and tools that produce tools that mediate that difference, rather than inventing our own...
[17:00] <lcs> the main advantage is it makes it more obvious to oracle sites, which SQL actually gets run.
[17:00] <mdiggory> lcs: I'll tolerate it... DS-297 that is
[17:00] * bradmc steps out, noting no meeting next week, and future meetings at 20:00 GMT only.
[17:00] <mdiggory> more obvious = better
[17:00] <stuartlewis> OK - anyone NOT happy with the change being made for 1.6?
[17:00] <bradmc> mdiggory / lcs : +1
[17:02] <stuartlewis> I've got to run now.
[17:02] <mdiggory> ok, Assume that is a go ahead on 297
[17:02] <stuartlewis> So - feature freeze a.s.a.p, pending stats, 297, and the last-modified xmlui stuff lcs is looking at?
[17:02] <lcs> yup, will try to have it in by this friday, i have to test with postgres though.
[17:03] <stuartlewis> I can then burn a final live cd once I land in the UK on Saturday.
[17:03] <lcs> stuartlewis: yes.
[17:03] <stuartlewis> See you all at DSUG.
[17:03] <stuartlewis> Gotta run. Bye.
[17:04] <mdiggory> ok
[17:04] <mdiggory> bye
[17:06] <mhwood> Wow, I mention ANSI SQL and everybody runs.
[17:06] <mdiggory> in terms of the javascript overlay stuff... there's really two options. "duplicate the code" or "don't duplicate it". And we duplicate other resources like images and css files, so I do not see the issue with this
[17:07] <mdiggory> The only other option is to engineer some fancy footwork to put it inot e dspace-api jar and pull it off the classpath when requested in the JSPUI and XMLUI. While its possible, thats yet more complexity
[17:07] <lcs> (a) those images and CSS files aren't *duplicated*, they are different evolutionary paths -- no manakin birds in the JSP ui.
[17:08] <lcs> (b) the JS code is common because it relies on common logic in the dspace-api layer
[17:08] <mdiggory> we already have a policy in place to maintain parity between the UI, this is just another case of it
[17:09] <lcs> it is really analogous to the input-forms stuff, which *is* shared becasue it lives in dspace-api.
[17:10] <mdiggory> I'd have to review the modification more closely, if theres presentation specific stuff in dspace-api, its probibly the wrong place for it
[17:10] <mdiggory> but that is configuration
[17:11] <lcs> it isn't presentation-specific, except at a very high level that says "use the suggest style" or "use the lookup style".
[17:11] <mdiggory> javascript is presentation
[17:11] <mdiggory> sorry I qualify... javascript run in the browser is presentation
[17:11] <lcs> javascript is also control logic. welcome to the world of AJAX.
[17:12] <mdiggory> control logic run int he browser is still part ofthe application/presentation layer
[17:13] <mhwood> Sorry, this *is* interesting, but I have to go. 'bye, all.
[17:13] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:13] <lcs> well, i don't have time for a philosophical argument.. let's get back to solving the problem.
[17:13] <mdiggory> Sorry, I will try to refocus on seeing if theres a solution, rather than presenting repeasted arguments
[17:14] <mdiggory> 1.) svn:externals would eliminate duplication, but they shouldn't be used to point at resources withinthe same svn project.
[17:14] <mdiggory> because that will make versioning quite painful
[17:15] <mdiggory> an option might be to place the javascript support in the repo/modules as a separate project and put externals pointing to there
[17:15] <lcs> The inadvertent-overlay solution *does* work, and as I see it your main objections are increased overhead (which i don't care enough about) and confusing ordering.. which is legit, but can be documented. that's why I chose the static/js subdirectory, to stay out of hte way of user mods.
[17:16] <mdiggory> still, if that code needs to change, those external may need to be readdressed
[17:16] <lcs> aiee! confusing svn tricks to make up for maven lossage? no.
[17:17] <mdiggory> not maven lossage... maven is just making us address the issue and resolve it by convention rather than hackery
[17:17] <mdiggory> and I'll admit that svn:externals are a bit of hackery
[17:18] <lcs> maven imposes its own preconceptions and limitations (which as you know, i find unreasonable).
[17:18] <mdiggory> again, I have no issues with duplicating this little bit of code in each UI, I think it actually a more consistent approach, because if you go about having to ever alter it... your going to have to be testing it in each UI seperately.
[17:19] <mdiggory> and if there are every differing requirements that arise in each UI, then there is room for the code to be adjusted
[17:21] <mdiggory> well... got a ton of other stuff to work on this afternoon... lets think about this during the time being... and address it later
[17:21] <lcs> testing both UIs.. that hardly happens in practice.
[17:22] <mdiggory> we have a policy of parity currently. testing in both UI's prior to release is a requirement
[17:22] <lcs> fine with addressing it later, got lots to do myself.
[17:22] <mdiggory> comments added to all the files in question would be adequate to assure that those altering "knew better"
[17:23] <mdiggory> or more specifically, "those commiting" knew better
[17:23] <lcs> you *know* what happens in the real world. Nobody reads those comments. unless every other line of source is a warning comment.
[17:24] <lcs> does svn have a way to set an alarm on a file so whenever you modify it, there's a reminder to say "modify this other one too"?
[17:25] <mdiggory> no
[17:26] <mdiggory> you can lock files, and a svn pre commit hook could be created, but thats a gastly awful idea I mention just to avoid it
[17:28] <lcs> we don't use locks, anyway, so a major change to development practice seems like a poor solution. (i'm just learning enough svn for survival.. CVS is what we use in-house, unfortunately.. i do admit svn is a big improvement.)
[17:28] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 54 (Connection reset by peer))
[17:29] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[17:42] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) Quit (Remote closed the connection)
[17:43] * grahamtriggs (n=grahamtr@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) Quit ()
[17:53] * tdonohue (i=80ae241d@gateway/web/freenode/x-cdmryswgtaxluxel) Quit ("Page closed")
[18:14] * ksclarke (n=kevin@adsl-227-149-169.clt.bellsouth.net) has joined #duraspace
[18:33] <bradmc> Or maybe a maven based test that alerts you during the build if the files diff. (Also yuck, but wouldn't need to run all the time).
[18:59] <mdiggory> the issue... not all the projects are always built at the same time... only during a release... this does introduce an opportunity to place something like that in the release process, which will limit it being part of everyday builds
[19:01] <mdiggory> the release process starts in the root trunk directory and, like the license plugin, something might be written to do such a check during the maven build... but, I'm just not so sure its relevant. what if the libraryis enhanced for one UI in ways that are not appropriate for the other? Not to be too critical of the group, but sometimes we can make a mountain out of a mole hill.
[19:03] <mdiggory> I advise we establish more design best practicies to assist developers in understanding what is and is not a best practice
[19:26] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 54 (Connection reset by peer))
[19:27] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:27] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) Quit ()
[22:04] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) Quit (Read error: 104 (Connection reset by peer))
[22:05] * stuartlewis (n=stuartle@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[22:53] * ksclarke (n=kevin@adsl-227-149-169.clt.bellsouth.net) Quit ("Leaving.")
[23:22] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[23:24] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 54 (Connection reset by peer))
[23:24] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[23:24] * mdiggory_ is now known as mdiggory
[23:32] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.