Timestamps are in GMT/BST.
[4:11] * snail (~stuart@130.195.86.37) has left #duraspace
[6:07] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[6:12] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Quit: mdiggory)
[6:14] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[6:16] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[6:43] -barjavel.freenode.net- *** Looking up your hostname...
[6:43] -barjavel.freenode.net- *** Checking Ident
[6:43] -barjavel.freenode.net- *** Found your hostname
[6:43] -barjavel.freenode.net- *** No Ident response
[6:43] [frigg VERSION]
[6:43] * DuraLogBot (~PircBot@duraspace.org) has joined #duraspace
[6:43] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[6:43] * Set by cwilper on Tue Jun 30 20:32:05 UTC 2009
[6:43] -barjavel.freenode.net- [freenode-info] please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
[7:03] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[7:04] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[7:52] * Tonny_DK (~thl@130.226.36.117) Quit (Ping timeout: 265 seconds)
[7:54] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[8:08] * pvillega (~pvillega@62.77.170.185) has joined #duraspace
[8:43] <pvillega> morning
[8:43] <pvillega> i will be around waiting for the meeting
[8:43] <pvillega> :)
[9:05] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[9:11] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[9:55] * pvillega_ (~pvillega@86.47.50.67) has joined #duraspace
[9:59] * pvillega (~pvillega@62.77.170.185) Quit (Ping timeout: 248 seconds)
[10:16] * Tonny_DK (~thl@130.226.36.117) Quit (Ping timeout: 265 seconds)
[10:17] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[12:08] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:31] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[12:45] * bojans (~Bojmen@91.118.67.67) has joined #duraspace
[12:49] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Quit: Leaving.)
[12:54] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:00] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[13:00] <pvillega_> hi
[13:00] <krnl_> hi
[13:00] * gsoc_yigang (~chatzilla@220.114.87.78) has joined #duraspace
[13:01] <mdiggory> Hello
[13:02] <bojans> Hi everybody
[13:02] <gsoc_yigang> Hi
[13:04] <mdiggory> Welcome to the first formal DSpace GSoC Meeting where we have all students together.
[13:05] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:06] <mdiggory> At this point, I did disclose that we would hold this meeting in the DSpace Developers IRC meeting on Wednesday, so there will hopefully be some other developers making their way in
[13:08] <mdiggory> I'll try to moderate this initial meeting and setup a informal agenda.
[13:10] <pvillega_> ok
[13:10] <mdiggory> 1.) Lets start with any technical issues or questions around development (such as svn access, maven, build environments)...
[13:12] <mdiggory> 2.) We could review current projects briefly, the goal being to expose the common areas of DSpace your all working on.
[13:13] <mdiggory> 3.) I we can discuss the status session of the DSpace Committers meeting on monday, and what it should be covering about your projects.
[13:15] <pvillega_> so, where do we start?
[13:16] <mdiggory> So to start things off simply, I believe we have everyone in the svn and the only ones I've not seen project spaces / commiting yet is krnl_ and bojans. are you setup properly at this time?
[13:17] <bojans> For me, I have an account from the last year, and it was working when I tried it a month ago.. so I have access there
[13:18] <krnl_> i will probably need a place in sandbox
[13:18] <krnl_> but currently playing around locally
[13:19] <mdiggory> krnl_: There are two approaches we can take with "storage", (1) is to place your work directly in the http://scm.dspace.org/svn/repo/modules/dspace-storage (2) branch the codebase for dspace trunk if you need it into the sandbox
[13:21] <mdiggory> I'm trying to promote your working within the modules project spaces as much as possible, and only in the sandbox where the project requires branching dspace code.
[13:21] <bojans> Ok I have just verified it again and svn works for me, the location is http://scm.dspace.org/svn/repo/modules/rest/
[13:22] <krnl_> i think i will need a location for dspace-api
[13:22] <krnl_> and storage-legacy
[13:23] <krnl_> also probably dspace-xmlui
[13:23] <mdiggory> krnl_: I assume will storage legacy be new code?
[13:23] <krnl_> yes
[13:23] <krnl_> well, maybe parts from dspace-api will go there
[13:26] * pvillega__ (~pvillega@86.47.50.67) has joined #duraspace
[13:26] <mdiggory> I will recommend that you try to (1) keep any modifications to dspace-api/xmlui in a branch that would become a patch to the dspace trunk (2) use modules for code that will be separate addons such as a LegacyDSpaceStorageProvider
[13:27] <krnl_> storage-legacy will be LegacyDSpaceStorageProvider
[13:28] <krnl_> everything else is ok with me
[13:28] <mdiggory> How much do you anticipate needing to change the dspace-api to create a storage provider?
[13:29] <krnl_> after a week of experiments on it, i think i will try make them as little as possible
[13:29] * pvillega_ (~pvillega@86.47.50.67) Quit (Ping timeout: 260 seconds)
[13:29] <krnl_> but still tehre will be some
[13:30] <mdiggory> What is the nature of the changes?
[13:30] <krnl_> probably moving out BitstreamStorageManager, DSpaceManager etc
[13:31] <krnl_> i'm actually still trying various combinations here
[13:32] <krnl_> and my proposal is that dspace-api is modified minimally and integration of storage-api is started on surrounding modules instead
[13:32] <krnl_> I'v been working on changes in dspace-api from last week, faced a lot of problems and probably leaning towards "gutting and wiring in" storage-api into DSpaceObjects as a first step. Second step should probably be dspace-xmui modification.
[13:35] <mdiggory> For others wondering where this is... https://wiki.duraspace.org/display/DSPACE/GSOC10+-+Backport+of+DSpace+2+Storage+Services+API+for+DSpace+1.x
[13:35] <krnl_> this is a little bit outdated, i will update that in next few days
[13:37] <mdiggory> In terms of the status updates, it would be best if everyone updated their wiki pages (I know some of you have) then get something out to the list asap. I will be traveling over the weekend and it would be good to have the most uptodate information on your project while I'm in the air.
[13:40] <mdiggory> for krnl_, I think a separate storage-api project would be sufficent for the storage api and mixins in dspace2.
[13:41] <mdiggory> I had actually pulled them out in a local workspace and placed them into dspace-services in the same location they were in within dspace2. If this would be easier or more helpful for you, we can place them there
[13:43] <mdiggory> Sorry, this was incorrect, I placed it into a new separate project... just to make sure you are aware of it
[13:43] <mdiggory> http://scm.dspace.org/svn/repo/modules/dspace-storage/trunk/
[13:43] <krnl_> i'm experimenting with it
[13:43] <mdiggory> This is a first point of overlap on gsoc_yigang's project and yours
[13:46] <mdiggory> gsoc_yigang is implementing the semantic storage provider (tupelo) by implementing this API project. What would be good to see is a possible collaboration/note taking activity on the API in the wiki. We could really use a critique of the API, trying to identify its weaknesses
[13:48] <mdiggory> your in a unique position because you have already worked with this API and Fedora, and now with DSpace Legacy, gsoc_yigang will be looking at it based on Tupelo. We need to know if the API makes sense or not for interacting with these storage systems.
[13:49] <mdiggory> Aaron Zeckoski and I designed the API while considering the implementation of it on JCR/Jackrabbit
[13:50] <mdiggory> But towards the end of the 2.0 funded development, this compromises were made in an attempt to "get to a running demostration"
[13:51] <mdiggory> One of these included the creation of StorageRelation, which needs to probably go away
[13:53] <mdiggory> are you two comfortable with getting together online and collaborating on some critiquing of the api?
[13:53] <krnl_> email is usually better for that
[13:53] <gsoc_yigang> email and irc are both OK for me
[13:54] <mdiggory> I would recommend email, but capturing the major points your project wiki afterwards.
[13:55] <mdiggory> bojans: Can you also voice any current concerns you have with the storage api based on our previous discussions about using it in your project?
[13:58] <bojans> For REST part there will be general necessity to use new points for invormation retrieval.. so I am working to prepare the REST module e.g. change current code and introduce new one on such way that these modifications cost less
[13:59] <bojans> Also we had discussions before.. I think for the storage api - triplestore we will need to introduce new or at least rivise current relations (ds:....)
[13:59] <mdiggory> Initially I know you had concerns about using it due to the startup timing of krnl_'s project, do you think we are going to end up with two different variants of the REST API initially?
[14:00] <bojans> From Aarons feedback from last week I started to work on both point and relation driven approach, which should coexist together
[14:02] <bojans> The relation driven one would be just an addition to current one, giving more options to the users and better control on requests/reponses
[14:03] <bojans> So from this point and experiments I had so far, I think we could have one variant at the end.. and maybe there will be some limitations (documented) related to differences in both versions (1.x and 2.x)
[14:03] <mdiggory> krnl_ and gsoc_yigang : I did have a conversation with bojans about some of the issues and design direction behind the storage api, which bojans reposted to the lsitserv.
[14:04] <krnl_> i read it
[14:04] <mdiggory> please to review it and borrow wherever it is useful
[14:05] <gsoc_yigang> OK, where's the conversation log? I've not read it.
[14:05] <bojans> GSoC student list, my last email with subject Status update
[14:06] <bojans> no REST / Storage comments
[14:06] <gsoc_yigang> Thanks
[14:06] <bojans> This is generally related to storage approach
[14:06] <bojans> Because many underlying things should be defined or decided on
[14:07] <mdiggory> I was trying to get a link to it here
[14:08] <mdiggory> http://sourceforge.net/mailarchive/forum.php?forum_name=dspace-gsoc-student
[14:08] <mdiggory> but it seems to not be current... Please look in your email
[14:11] <mdiggory> I agree, I know I've said I have some changes in the api that I am working on, due to OR10 and other obligations those are not complete yet. Plus the development was slower on the api changes because I was trying to keep the current storage implementations tests passing at the same time.
[14:11] <krnl_> understandable
[14:11] <mdiggory> I also would like to consider if this api changing activity might better be a project for you guys to be doing as part of your project?
[14:12] <krnl_> i was thinking on proposing that i will overtake it till some level
[14:13] <bojans> I could probably for on it also up to some level as the effort on main project may be variable
[14:13] <mdiggory> This would be very helpful and I think it would be appropriate.
[14:14] <mdiggory> gsoc_yigang: how much has you work depended on the current storage-api? I assume significantly?
[14:15] <gsoc_yigang> I've just refactored the whole architecture to introduce a new service: TupeloService
[14:16] <gsoc_yigang> The TupeloService and its implementation has been developed with unit tests.
[14:17] <mdiggory> So on your project, we are not at the point where there is any reliance on the existing storage-api correct?
[14:17] <gsoc_yigang> I'm working on developing TupeloStorageService based on TupeloService.
[14:18] <mdiggory> Ok, so at this point, having the API present, even if it breaking other service tests such as JCR is acceptable?
[14:18] <mdiggory> pvillega__: I expect you to be keeping us aware we need to be using test driven development practices here ;-)
[14:19] <pvillega__> :D he is using tests, is fine
[14:19] <pvillega__> right now my concern, but I think we can discuss it later, is if the changes they will do to the content package won't impact my tests
[14:20] <pvillega__> but it is a minor concern
[14:22] <mdiggory> I expect, given we are working in branches/modules that we can develop a process that assures testing works across the different projects?
[14:22] <pvillega__> yes, as I documented in the wiki, I created a new module for the testing, where all test cases can be added. So new modules can benefit from the infrastructure prepared for DSpace unit tests
[14:23] <mdiggory> Speaking of which... pvillega__: I do have a topic for us to discuss concerning CI for the projects... In your testing approach are you using any CI setup at the moment?
[14:23] <pvillega__> there are some concerns there (on the current test module), but maybe we should finish the discussion you were having .
[14:23] <pvillega__> on the CI, it should work straight away with Maven and CI
[14:24] * gsoc_yigang (~chatzilla@220.114.87.78) Quit (Read error: Connection reset by peer)
[14:24] <mdiggory> I think we are at the point where we can switch topics.... krnl_ I'm planning to commit the API / Test changes to storage-api and storage-impl and you can pick them up from there.
[14:24] * gsoc_yigang (~chatzilla@220.114.87.78) has joined #duraspace
[14:25] <mdiggory> it will break, but that is motivation to move it forward as well
[14:25] <krnl_> ok
[14:28] <mdiggory> so pvillega__ how much of what you modified in the branch was outside of http://scm.dspace.org/svn/repo/sandbox/gsoc/2010/testing/dspace-test/
[14:29] <pvillega__> mmm i would say only a change in pom.xml, I moved all top dspace-test. My concern was more on changes to dspaceobject, but thinking about it, should not be a problem
[14:29] <pvillega__> the only think I don't like (As I mentioned in the mail) is that I had to replicate part of the filesystem of dspace
[14:29] <pvillega__> config, license, etc
[14:29] <pvillega__> i can't see a better solution, but we should find one :)
[14:30] <mdiggory> What I am going to suggest is trying to see if we can get some initial usage of your test harness.
[14:30] <pvillega__> yes, it should be ready
[14:31] <mdiggory> a question for everyone, just verifying.... what are your development environemtns / IDE?
[14:32] <krnl_> eclipse
[14:32] <bojans> netbeans
[14:32] <pvillega__> netbeans 6.9/kubuntu 9.10
[14:32] <gsoc_yigang> eclipse
[14:34] <mdiggory> Ok, so in each of the cases, we can checkout separate codebases as projects or modules in the IDE. pvillega__ do you think it would be in scope for you come up with direction for the others that might allow them to be able to checkout dspace-test into their workspace and run the tests against local code changes they are making?
[14:35] <mdiggory> Ideally this would be with just the test harness, not your branch of the other project code like dspace-api / etc
[14:36] <pvillega__> mmm yes, I can document it
[14:36] <pvillega__> well, it should be as simple as them downloading the code and merging it
[14:36] <mdiggory> and moving back a step, do you think this would be useful in their development process?
[14:37] <pvillega__> well, TDD is always good, makes you think a bit more on the code and captures errors
[14:37] <pvillega__> even if it takes some time from their project, it would eb good long term
[14:37] <pvillega__> that said, I think some were already using unit tests
[14:37] <pvillega__> if that system was working for them, that could be ok
[14:38] <pvillega__> I'm thinking that they are not using the Dspace database but other storage
[14:38] <mdiggory> yes they are, as dspace2 uses tests originally
[14:38] <pvillega__> so probably myc lasses, whichuse h2 in memory to replicate the environment, would not benefit them too much
[14:38] <pvillega__> so probably my classes, which use h2 in memory to replicate the environment, would not benefit them too much
[14:38] <mdiggory> per storage... right, not yet using dspace db... but krnl_'s work may hit core classes and the database with changes
[14:39] <pvillega__> then, yes, it may be useful for him
[14:41] <mdiggory> the storage-db implementation initially is testing against DERBY and HSQLDB
[14:42] <mdiggory> http://scm.dspace.org/svn/repo/modules/storage-db/trunk/src/main/java/org/dspace/services/storage/database/StorageEntityDAO.java
[14:42] <pvillega__> i had issues with hsqldb, that's why i moved to h2
[14:42] <pvillega__> but it should not be a problem to go back if required, to hsqldb
[14:42] <mdiggory> I do wonder if this can be made a bit more flexible, I'm concerned about seeing decisions on database environment hardcoded in the implementation classes
[14:43] <pvillega__> the mock class I have takes the configuration form dspace.cfg
[14:43] <mdiggory> so db driver / url / etc?
[14:43] <pvillega__> yes. But right now, the postgresql/oracle presence in the code is "strong" at the very least, so some changes are required
[14:44] <pvillega__> I solved that via a mock of DatabaseManager
[14:44] <mdiggory> Understandable... very understandable
[14:44] <pvillega__> but the original class has many "if oracle then else"
[14:45] <mdiggory> yes, those are very troublesome.
[14:45] <pvillega__> I have a question, there is any plan of integating an ORM into DSpace?
[14:45] <pvillega__> like Hibernate?
[14:45] <mdiggory> in Spring, one might use JDBCtempaltes to encapsulate that
[14:46] <mdiggory> I know of interested parties that have experimented
[14:46] <pvillega__> that would solve many problems
[14:46] <mdiggory> Andrea Bollini for one...
[14:49] <mdiggory> This is where some design and technology direction in the DSpace community needs to happen. There was a rather ambitious project the Jim Rutherford started while at HP prior to the dspace2 work... this refactored all the DSpaceObject classes into DAO... but there were other extenuating circumstances that lead to the demise of that branch.
[14:50] <mdiggory> but the goal was to at least peal off the database persistence code from the DSpaceObjects and encapsulate that in DAO objects
[14:50] <mdiggory> after which that layer could be reimplemented in a number of ways, one of which was under consideration was Hibernate
[14:51] <mdiggory> this was the precursor to the dspace2 work.
[14:51] <pvillega__> sounds like an interesting GSC project :)
[14:55] <mdiggory> I occasionally find myself looking at the DSpaceObject classes and considering that at lease having a Factory, Interface, DAO would enable future reimplementation
[14:57] <mdiggory> the degree of refactoring will, however, raise flags with many of the commiters
[14:58] <pvillega__> yes, I can understand that
[14:59] <mdiggory> this is where implementing something new from scratch for DS2 became an intitiative.
[15:01] <mdiggory> one area that dspace-storage may benefit from your experience with h2 and hibernate may be in (1) providing some guidance on improving the testing in the storage-db case and (2) exploring what a hibernate version of storage-db might look like.
[15:03] <pvillega__> I have no problem in helping, any questions I'm here, if I need to do some code just ask :)
[15:05] <gsoc_yigang> I need "AbstractStorageServiceTest" for testing the new triplestore. It does not work well now. How can I get it?
[15:05] <mdiggory> So... the Storage DAO / tests are very independent of implementation... http://scm.dspace.org/svn/repo/modules/storage-db/trunk/src/test/java/org/dspace/services/storage/StorageEntityDAOTest.java
[15:06] <mdiggory> but, somewhere in the implementation code, things to get very sepecific to derby/hsqldb
[15:06] <mdiggory> http://scm.dspace.org/svn/repo/modules/storage-db/trunk/src/main/java/org/dspace/services/storage/database/StorageEntityDAO.java
[15:07] <mdiggory> I know there are even more specific code/configs
[15:08] <pvillega__> sorry guys but I have to leave the computer for a while
[15:08] <pvillega__> I'll be back in 30m or so, will read what you write
[15:08] <mdiggory> Ok, we need to finish upt he official meeting anyhow.
[15:09] <pvillega__> to the other developers if I can help you with the unit testing, please send me an email to pere.villega --at-- gmail.com
[15:10] <mdiggory> excellent, and consider how best we can include your choice in h2 into the dspace-storage areas
[15:10] <mdiggory> maybe for next time
[15:10] <mdiggory> I'll flag this point as the end of the meeting
[15:10] <mdiggory> Before we close, I would like to arrange for our next meeting, this time I'll organize and send email to the developers list as well
[15:11] <bojans> next week or?
[15:11] <mdiggory> because next week is OR10, there are some challenges, but also some benefits
[15:11] <mdiggory> one benefit it time zones
[15:12] <mdiggory> I will be in Spain so that will allow us to meet earlier.
[15:12] <mdiggory> however, I will also be very busy
[15:14] <mdiggory> Lets plan to discuss it over the email list, tentatively lets see if there is a time next week that would work, if not, I will suggest the monday or tuesday of the week after
[15:14] <bojans> ok
[15:14] <gsoc_yigang> OK
[15:16] <krnl_> ok
[15:18] <gsoc_yigang> have a nice trip to Spain, :)
[15:22] <mdiggory> thanks, have a good weekend, and a reminder to please do send out those updates so I can use them for the meeting next week, cheers.
[15:55] * pvillega (~pvillega@62.77.170.185) has joined #duraspace
[15:59] * pvillega__ (~pvillega@86.47.50.67) Quit (Ping timeout: 260 seconds)
[16:04] * gsoc_yigang (~chatzilla@220.114.87.78) Quit (Quit: ChatZilla 0.9.85 [Firefox 3.5.9/20100315083431])
[16:30] * pvillega (~pvillega@62.77.170.185) Quit (Remote host closed the connection)
[16:41] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) Quit (Quit: mdiggory)
[16:42] * mdiggory (~mdiggory@ip72-199-217-116.sd.sd.cox.net) has joined #duraspace
[17:16] * ksclarke (~kevin@adsl-39-28-234.clt.bellsouth.net) has joined #duraspace
[17:27] * bojans (~Bojmen@91.118.67.67) Quit (Remote host closed the connection)
[21:19] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Remote host closed the connection)
[21:48] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[21:52] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[21:52] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.