Timestamps are in GMT/BST.
[0:06] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[2:53] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[3:48] * Tonny_DK1 (~thl@130.226.36.117) has joined #duraspace
[3:48] * Tonny_DK (~thl@130.226.36.117) Quit (Read error: Connection reset by peer)
[4:10] -hubbard.freenode.net- *** Looking up your hostname...
[4:10] -hubbard.freenode.net- *** Checking Ident
[4:10] -hubbard.freenode.net- *** No Ident response
[4:10] -hubbard.freenode.net- *** Found your hostname
[4:10] [frigg VERSION]
[4:10] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:10] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:10] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[7:09] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[8:08] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[9:02] * ksclarke (~kevin@cpe-065-184-178-177.ec.res.rr.com) has joined #duraspace
[9:15] * Tonny_DK1 (~thl@130.226.36.117) Quit (Quit: Leaving.)
[9:28] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[11:20] * achelous (~tom@216.160.210.151) has joined #duraspace
[11:31] * achelous (~tom@216.160.210.151) Quit (Remote host closed the connection)
[11:35] * achelous (~tom@216.160.210.151) has joined #duraspace
[11:36] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[11:52] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[13:49] * achelous (~tom@216.160.210.151) Quit (Ping timeout: 240 seconds)
[14:04] * achelous (~tom@174-126-228-87.cpe.cableone.net) has joined #duraspace
[14:16] * achelous (~tom@174-126-228-87.cpe.cableone.net) Quit (Ping timeout: 240 seconds)
[14:18] * achelous (~tom@174-126-228-87.cpe.cableone.net) has joined #duraspace
[15:09] * achelous (~tom@174-126-228-87.cpe.cableone.net) Quit (Ping timeout: 258 seconds)
[15:27] * achelous (~tom@216.160.210.151) has joined #duraspace
[15:38] * bojans (~Bojmen@91.118.57.172) has joined #duraspace
[15:42] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[15:43] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[15:45] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:45] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[15:46] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:59] <tdonohue> Hey all-- Here's the DSpace Developer Mtg agenda for today: http://wiki.dspace.org/confluence/display/DSPACE/DevMtg+2010-06-16
[16:01] <tdonohue> We can start with a congrats on 1.6.2 -- nice quick turnaround on the few bugs we found in 1.6.1!
[16:01] <mhwood> [applause]
[16:02] <PeterDietz> good work all
[16:03] <tdonohue> And, thanks to kshepherd and stuartlewis for helping to really push this one through quickly -- great job
[16:04] <tdonohue> (oh, and keithg for helping with the testing/verification of that 'start-handle-server' accidental breakage)
[16:04] <tdonohue> Ok --- I don't have any specific updates on GSoC, and I notice mdiggory isn't here right now. Does anyone else have GSoC updates to share? stuartlewis, maybe?
[16:05] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) has joined #duraspace
[16:06] <tdonohue> ok -- we'll move along for now, as our GSoC mentors are currently missing ;) -- we can squeeze in a GSoC update later on if needed
[16:07] <tdonohue> For those who will be at OR10 and able to attend our pre-conference committers mtg, I've started drafting up a very 'tentative' agenda here: http://fedora-commons.org/confluence/display/DSPACE/DevMtg+2010-07-05+-+OR10+Meeting
[16:08] <richardrodgers> I don't see anything about beer
[16:08] <tdonohue> richardrodgers -- search for "bar/tapas" ;)
[16:09] <richardrodgers> tdonohue: got it :)
[16:09] <tdonohue> The schedule / agenda is still very tentative -- if any of you have topics you'd specifically like to discuss (or proposals for us to react to), please let me know -- we have room on the agenda
[16:10] * PeterDietz will look into the world cup schedule
[16:10] <tdonohue> Currently, we're scheduled to start at noon and run till ~5-6pm (or whenever tapas break begins for everyone else)..... But, we can move that time around if we want to -- we technically have the room all day long.
[16:11] <richardrodgers> I forget is there a PASIG conflict?
[16:11] * mdiggory (~mdiggory@12.89.70.134) has joined #duraspace
[16:11] <tdonohue> richardrodgers -- yes...unfortunately. PASIG is scheduled for *all day*, in a totally different location (we tried to get them to schedule at the University as well)
[16:12] <tdonohue> So, if people want to attend part of PASIG -- we can try and make time for it --- though it will be a bit of a trip to get over there I believe
[16:12] <tdonohue> Essentially, I'm looking for feedback on the current agenda/schedule -- we can shorten the meeting time if there are too many conflicts for most.
[16:13] <tdonohue> mdiggory: we're discussing the OR10 pre-conference mtg: http://fedora-commons.org/confluence/display/DSPACE/DevMtg+2010-07-05+-+OR10+Meeting
[16:13] <tdonohue> FYI -- the PASIG meeting info is here: http://www.oracle.com/webapps/events/EventsDetail.jsp?p_eventId=113053&src=6882794&src=6882794&Act=6 (and you'll notice it runs all day long)
[16:15] <richardrodgers> tdonohue: as a general reaction to agenda, I agree roadmap planning is a good topic
[16:16] <tdonohue> yea, i figured that would be a "hot topic" and worth digging into more
[16:17] <tdonohue> I know I just threw this in front of you, so feel free to give more feedback later -- I'll also send out a note to committers after this mtg, and we can try and work the meeting time around our schedules as needed. I'd like to get our meeting time finalized soon though
[16:17] <mdiggory> Yes, this is an important meeting, so scheduling it for maximum participation is critical
[16:18] <tdonohue> exactly -- I'd also like to ensure we can have 3-4 hrs together (if possible) -- as there are some topics worth digging into
[16:18] * kshepherd sneaks in
[16:19] <mhwood> There he is!
[16:19] <kshepherd> argh
[16:19] <PeterDietz> btw, there is no world cup on monday july 5 -- http://www.fifa.com/worldcup/matches/kostage.html -- there are games on T-6th, W-7th, Sa-10th, and Su-11th all at 8:30pm
[16:19] <tdonohue> that's one less conflict then ;)
[16:20] <tdonohue> jumping back to GSoC topic -- mdiggory, did you have any specific updates on GSoC to give us?
[16:22] <mdiggory> Nothing significant. We have 1 month until the midterm. Students should be active on their projects and starting to solidify the work they will be graded on at that time
[16:22] <mdiggory> I've had discussions with Yigang, Bojan and Andrius about collaborating on parts of the StorageService api.
[16:23] <mdiggory> I am concerned still that the kind of email list activities I had hoped for are not happening
[16:24] <tdonohue> is there anything we can do to encourage that, or is it just a matter of the students "getting their feet wet" so to speak (i.e. they are still very early on in projects)
[16:24] <mdiggory> how do we get students to engage the mentors on their projects design? Status updates would not be a necessity if there was engagement.
[16:26] <mdiggory> I think that having someone confirming that status updates are happening is critical. Unfortunately, my time is very limited, this is part of the administrative duties to push the agenda
[16:27] <mhwood> It's tough. Mentoring is different from what students will be used to.
[16:28] <richardrodgers> Although aren't 2 of 3 GSCO vets?
[16:28] <richardrodgers> GSCO->GSOC
[16:28] <mdiggory> Yes, and also present in the room AMT ;-)
[16:28] <mdiggory> AMT --> ATM
[16:29] <mdiggory> krnl_: and bojans how do you feel about this topic? How does participation on the email lists effect you? Do you feel there is a hinderance?
[16:30] <mhwood> So, what (briefly) do you think engagement with a mentor looks like?
[16:30] <tdonohue> I think the key is just to encourage more interaction (hi GSoC students), and I think the mentors should work with them to get regular, scheduled updates in a timeframe that works well for both of them.
[16:30] <tdonohue> It also would help to try and get many of those updates to happen directly on 'dspace-gsoc-student' list, which can help promote cross-project interaction/discussion
[16:31] <krnl_> no, I think emails will possibly roll out a little bit later
[16:32] <krnl_> and we do have some time after this meeting right?
[16:32] <mdiggory> that is really all I want to see, I've tried to clarify various times where students would all be able to be online together. We do need to see them working together on the topics.
[16:32] <bojans> Hi all, I can say something from my perspective / for myself and maybe particular that can be applied for others.. so regarding status of the work, GSoC starts generally in time which is criticall for semester-end
[16:32] <mdiggory> Yes, but we know that this time after the meeting is not conducive for one of our students
[16:33] <tdonohue> sure, you are welcome to discuss more after this meeting (although I have another mtg to head to today)
[16:33] <bojans> .. also for the requirements and implementations, in the beginning I was expecting something else than it has been brought later to, so for my part I had to invest some additional time to inspect the code
[16:33] <krnl_> common work is ecouraged, but still there are questions which affect mostly one particular student
[16:34] <bojans> My proposal would be also to schedule not 1 but 2 weekly meetings of students
[16:35] <tdonohue> bojans -- that makes sense that early one you'd need more time to inspect code, etc.
[16:35] <mdiggory> So what I'd like to see the students and mentors (myself included) attain, is a finalized schedule for those meetings
[16:35] <bojans> I suppose it is necessary as once a week workin together on the projects and their interfacing is maybe no enough e.g. the traction can be loosed
[16:36] <mdiggory> stuartlewis has said that he can't really make the time I proposed, but also said it was not necessary that he be present and would be available over email
[16:37] <stuartlewis> Yep
[16:37] <tdonohue> mdiggory & bojans -- I'd agree -- it'd be good to try and finalize a time for the students to meet at least once a week. (if not twice).
[16:37] <stuartlewis> The meeting would be at mignight for me. So if I drop out, it means the meeting can be moved two hours later to make it easier for mdiggory
[16:37] <tdonohue> it'd also be good to publicize that, so that others devs can attend (if they can make it)
[16:37] <bojans> Yes generally said the time goes relativelly fast and one month to the mid-term means 4 meetings
[16:39] <tdonohue> Ok -- well, it sounds like there's a TODO out of this -- so, I'm going to move onto the next topic for now. mdiggory, let me know if you need anything else
[16:39] <mdiggory> So I originally proposed a time of 12:00 UTC... we have an email thread where we left off on setting up a schedule... and this needs to be further settled on
[16:40] <mdiggory> that discussion should continue in the thread, but I first propose we setup something for the end of this week
[16:40] <mdiggory> and I'll fire out an email to reinitiate this
[16:41] <tdonohue> mdiggory -- other possible solution to throw out there -- if one time doesn't work perfectly for all, maybe you can stagger meetings (at two different times), and try and catch the majority of folks at one of the meetings (if some students cannot make both, then hopefully they can catch up via email)
[16:42] <tdonohue> ok -- so, it's now been 3 weeks since our last DSpace Services Framework discussion -- are there any other thoughts on this work? Have folks had a chance to review it and try it out a bit?
[16:42] <mdiggory> point taken...
[16:43] <mdiggory> I've gotten some feedback from Yigang on the services framework as he has been preparing for doing his project using it.
[16:43] <mdiggory> He said he found it to be very sensible
[16:43] <tdonohue> 3 weeks ago we had talked about needing some more time to review the Services Framework -- have people had enough time? Do we 'table this' for deeper discussion at our OR10 meeting?
[16:44] <mdiggory> I think that without specific activities, your not going to get much more than this
[16:44] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[16:44] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:44] <tdonohue> From the basic review I've done -- I like the framework so far (though I'm still learning), with the exception of my points about package naming (which I sent already in a thread on dspace-devel)
[16:45] <mhwood> I'm still a bit unclear on what makes a good service, how you know when you're thinking of creating something that should be a service.
[16:45] <richardrodgers> I think review in isolation is not the most productive use of time. Like mdiggory just said, it's concrete engagements that teach us
[16:45] <mdiggory> At this point, for me its not about adopting the services framework, its about clarifying how to use the services
[16:45] <kshepherd> i haven't had time to study it as much as i want to, but things have been pretty hectic for me. i should be more up-to-speed over the next month or so
[16:45] <mhwood> "Clarifying how to use the services" -- yes.
[16:46] <tdonohue> point taken, mdiggory & richardrodgers
[16:46] <mdiggory> For instance, take the ConfigurationService, detailed examples of "how do you use it instead of using ConfigurationManager"
[16:47] <mdiggory> Likewise, witht he EventService, theres still work adapt it to work with or replace the EventManager
[16:47] <mdiggory> Finally for the StorageService, which directly relates to the GSoC projects, where /how does it replace capabilities in the current BitstreamStorage servce and Database
[16:48] <tdonohue> So -- perhaps the question is -- would anyone like to volunteer to work on 'clarifying how to use the services' -- or, can we all make an attempt to try to use them more in our current/future developments
[16:49] <tdonohue> I guess my point is -- I'd rather us not keep forgetting about the services framework and move forward without it -- it'd be nice to start to talk about projects which could utilize it that could go into 1.7 or later (but maybe that's a roadmap discussion for at OR10)
[16:49] <mdiggory> What I'd really like to see is the expansion of the following page with more details and code examples
[16:49] <mdiggory> http://wiki.dspace.org/confluence/display/DSPACE/DSpace+Services+Framework
[16:50] <mdiggory> and the correction of the current examples to support some recent changes to allow more flexible configuration of the core services at startup
[16:50] <mdiggory> TBH, you need to understand that significant portions of this come from the original DSPace 2.0 docs authored by Aaron
[16:52] <mhwood> I need to read it over again (and again).
[16:52] <tdonohue> Ok -- that makes sense to fill that page out a bit more. In general, it'd just be good to think about how we could use this framework more going forward (so, keep it in mind as you develop local changes, etc)
[16:52] <tdonohue> we can leave it at that -- you're right that we need all likely need to work with it more on a real project before we can really provide the feedback it needs
[16:53] <mdiggory> So for instance, theres a significant lack of proper "linking" between the codebase itself and the wiki. It would be good to see references to code and interfaces where appropriate. Also it would be good to have an example Addon Module available that reflects examples of how to add services activators providers and listeners
[16:53] <mhwood> When I see an opportunity I will pick something I'm doing and make it use at least one Service.
[16:54] <tdonohue> mhwood -- good goal, thanks! I'll work to do the same :)
[16:55] <tdonohue> mdiggory -- I'd agree we should have more linking between codebase & wiki -- just a matter of someone starting a 'best practice' and trying to get everyone else to add similar docs -- I think what you've started around the Discovery project could become that sort of best practice
[16:55] * tdonohue notes I have another meeting to run to at top of hour
[16:56] * mdiggory notes I need more caffene
[16:56] <tdonohue> Any quick comments on the other topic -- Smaller License headers in our Code? See email thread: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg03587.html
[16:57] <richardrodgers> Seems OK with me - provided we do get a competent legal nod
[16:57] <mhwood> If laywers and administrators are happy with it, I would be glad to have smaller boilerplate.
[16:58] <mdiggory> Quick comment... by adopting the dspace-pom as our parent pom, we can alleviate many licensing formatting issues on release. And likewise, enforce our requirements on all file prior to cutting releases.
[16:58] <tdonohue> bradmc has given his approval, and very similar text has been approved by UVA lawyers for Fedora (in past). The only change we've made to that approved text is the location of the external license file.
[16:58] <mhwood> dspace-pom is something new?
[16:58] <tdonohue> mdiggory -- sounds like something to think about for 1.7?
[16:58] <mdiggory> dspace-pom is the parent used in the modules directory for new modules
[16:59] <richardrodgers> but are the licences the same? I.e. does Fedora precedent work for us?
[16:59] <mdiggory> its usage is similar to the manner parent poms are used in the Apache projects
[17:00] <tdonohue> richardrodgers -- we aren't changing our dspace license at all (that remains the same) -- all we are suggesting to change is the *header* at the top of files (and we're changing the header to a nearly identical one to the Fedora project)
[17:00] <mdiggory> I.E. less rules on dependency management more on just java environment and release processing
[17:00] * mhwood 's Infinite Reading List gets another entry.
[17:00] <tdonohue> mhwood -- i often feel the same way (infinite reading list)
[17:00] <mdiggory> and its mantained separate from the modules and released on its own schedule
[17:01] <richardrodgers> tdonohue: got that, I just meant some licenses may be more 'by reference' friendly than others...
[17:01] <tdonohue> ok -- I've gotten run to another meeting -- i hate to run out like this. Feedback welcome on the OR10 meeting, and also on the header idea, etc.
[17:02] <mdiggory> likewise, we avoid placing any dependencies or dependency management into any maven pom that is for modules... instead leaving dependency management to those projects that actually produce jar and war artifacts
[17:02] <tdonohue> richardrodgers -- i'll bring it up again, but so far the overwhelming response in DuraSpace is that it's already been approved as part of Fedora project (and as our license itself isn't changing, it's likely the lawyers won't care). Unless you'd like to bring it up with MIT lawyers? ;)
[17:03] <tdonohue> gotta run -- meeting closed, but feel free to continue discussion as needed
[17:03] <richardrodgers> I might do a quick check, but nothing with MIT lawyers is quick ;)
[17:03] <mdiggory> so tdonohue allt hat really leaves is updating the template in the svn repo
[17:03] <mdiggory> http://scm.dspace.org/svn/repo/licenses/LICENSE_HEADER
[17:04] <mdiggory> which is where dspace-pom picks it up when you execute mvn license:format
[17:04] <mdiggory> and all file in a project then either have it added or verified
[17:04] <richardrodgers> Also have to go, thanks all!
[17:04] * richardrodgers (~richardro@pool-173-76-18-245.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[17:05] <mdiggory> and mvn license:validate outputs which licenses need to
[17:05] <mdiggory> all existing license headers will get replaced by whatever is int hat template
[17:07] <mdiggory> ok, I'm taking 5 then if theres any GSoC activities I will be available
[17:07] <mhwood> Thanks for exposition on the license stuff -- will read up on it.
[17:07] <mhwood> Must go, thanks, all!
[17:08] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[17:13] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[17:14] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: keithg)
[17:16] <krnl_> Just to consolidate meeting ideas some time ago: shim over the old DSpace API means that LegacyStorageProvider will have references to DSpaceObjects and DSpaceObjects will not be changed?
[17:16] <mdiggory> ok, that was where the IRC discussion left off
[17:16] <mdiggory> but is the popular approach the best approach, that is the question
[17:18] <mdiggory> likewise, we need to get clear what are the requirements for other services and support that are going to be needed
[17:18] <mdiggory> for instance with Metadata registry support
[17:18] <mdiggory> and BitstreamFormat support
[17:19] <mdiggory> but yes, one of the positives of shimming is that the "validation" of any change is done under the storage service in the provider
[17:20] <mdiggory> so if that validation is simply the provider not having a setter or getter on a legacy dspace object, thats pretty easy
[17:22] <mdiggory> the point of the storage api is to end up with a non-object oriented data model.... I.E. we are modelling attributes and relations on one type of object, not different types of objects
[17:22] <mdiggory> type is just another attribute....
[17:22] <mdiggory> the goal is to not have to use java classes to model metadata classes
[17:23] <mdiggory> and thus not need java programming abilities to create a "Content Model"
[17:23] <krnl_> agree
[17:23] <krnl_> so you Mark basically support this shim idea?
[17:24] <mdiggory> I tolerate it as a possibly a necessary evil.
[17:25] <mdiggory> but would like to think that the true "2.0" implementations may have little to nothing to do with those data objects
[17:25] <mdiggory> so, for instance a fedora provider or a triplestore provider will back anything in org.dspace.content
[17:26] <mdiggory> will back = will not back)
[17:26] <mdiggory> and instead they will be interacted with through the same storage API as is being shimmed.
[17:27] <mdiggory> This does however open a larger can of worms that we left closed for a long time...
[17:28] <mdiggory> how/what happens to MetadataSchema/Fields if we have no DSpace "Item"
[17:28] <mdiggory> and how do we informt he user interface and/or provide validation of a "Content Model" in DSpace
[17:29] <mdiggory> generally, at the moment, this is enforced by the application at many different levels.
[17:29] <mdiggory> Submission UI / Inputforms, MetadataRegistry, BitstreamFormatRegister
[17:31] <mdiggory> My questions for you are to consider how (1) the shim mediates exceptions when invalid properties are set on entities that represent these data model types
[17:32] <mdiggory> (2) how will we continue to be able to access these various "services" through the service manager or storage manager if we are not interacting with them directly...
[17:32] <mdiggory> and... you can push back / critique here...
[17:33] <mdiggory> A big question that I've had lately is if the REST api itself is ultimately the boundary between the application and the services teir
[17:33] <mdiggory> which is ultimately what I think Aaron intended in the design.
[17:34] <mdiggory> and this is a question that should also be assessed by bojans as well
[17:35] <mdiggory> Right now we have "REST <--> Provider <--> DSpaceObject <--> Persistence"
[17:35] <mdiggory> and are proposing
[17:36] <mdiggory> for legacy shim....
[17:36] <mdiggory> "REST <--> StorageService <--> Provider <--> DSpaceObject <--> Persistence"
[17:36] <mdiggory> and for the triplestore / fedora projects
[17:36] <mdiggory> "REST <--> StorageService <--> Provider <--> Fedora/Tirplestore <--> Persistence"
[17:36] <krnl_> EntityProviders will have to be rewritten to use storage-api?
[17:37] <bojans> So for me it seems that the providers will be moved to another modules and REST is interacting with StorageService directly
[17:38] <mdiggory> krnl_: possibly, yes
[17:38] <bojans> e.g. StorageService and Provider are doing mapping and translating objects
[17:38] <bojans> but there may be other ways probably
[17:38] <mdiggory> that is a suggestion
[17:39] <bojans> Based on this the REST is just simple outer layer and right job is done in these other modules
[17:39] <mdiggory> We need to think good and hard about what REST does with other services that are not "storage-service"
[17:40] <mdiggory> for instance, there is a UserService that is used to abstract managing users and permissions
[17:41] <bojans> Currently for me it seems that it would be better to do this mapping one step earlier e.g REST <-> Map <-> Storage/User...
[17:41] <bojans> but maybe I am not catching it all
[17:43] <bojans> Is there some specific reason this proposal is based on?
[17:43] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[17:43] <mdiggory> problems I can forsee... a.) we like to work in java... b.) that what is defined to be available in the rest api would then need to be retrievable from the storage service....
[17:43] <bojans> For instance, some concerns or architectural suggestions?
[17:44] <mdiggory> I do have to finish up here and leave in 5 minutes
[17:44] <bojans> ok
[17:44] <krnl_> ok
[17:45] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[17:45] <mdiggory> that means right now we get away with the DSpace Community, Collection, etc provider having the allowed parameters practically hardcoded into it/
[17:45] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[17:45] <krnl_> Mark, you have mentioned that you are making changes to dspace-api locally. Are these mainly the changes you described at http://www.fedora-commons.org/confluence/display/DSPACE/GSoC+Collaboration+Scratchpad ?
[17:45] <mdiggory> and so when those need to be tested in the REST request... you have a very specific place to setup the rules
[17:46] <mdiggory> dspace-storage/api is what I've been looking into changing
[17:46] <krnl_> yes :)
[17:46] <krnl_> sorry
[17:46] <mdiggory> and thats nothing concrete yet
[17:46] <mdiggory> as briefly as possible...
[17:47] <mdiggory> that is (1) making StorageEntity just an identifier
[17:47] <mdiggory> and (2) removing StorageProperties from StorageEntity
[17:48] <mdiggory> and (3) adding methods tot he Service to get back sets of StorageProperties for an Entity
[17:48] <mdiggory> and update / delete Sets of StorageProperties.
[17:48] <mdiggory> the objective is to make it so that the Service is more like the interface to a Triplestore
[17:49] <mdiggory> which was what I intended origanally when we started the project, but failed to retain as it evolved to support JCR
[17:50] <krnl_> I think dspace-storage api should be the priority here
[17:50] <mdiggory> ok, really have to run now... seriously, do throw any questions to me over email that you have, I will work to answer them during the same day
[17:50] <krnl_> ok
[17:50] <bojans> ok, thanks
[17:50] <mdiggory> definitely, it is the focal point of each of your projects
[17:51] <mdiggory> I'll be online later.
[17:51] * mdiggory (~mdiggory@12.89.70.134) Quit (Quit: mdiggory)
[17:51] * mdiggory (~mdiggory@12.89.70.134) has joined #duraspace
[17:51] * mdiggory (~mdiggory@12.89.70.134) Quit (Client Quit)
[17:54] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[17:59] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[18:32] * bojans (~Bojmen@91.118.57.172) Quit (Read error: Connection reset by peer)
[18:34] * bojans (~Bojmen@91.118.57.172) has joined #duraspace
[18:44] * bojans (~Bojmen@91.118.57.172) Quit (Remote host closed the connection)
[19:12] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[21:16] * achelous (~tom@216.160.210.151) Quit (Ping timeout: 260 seconds)
[21:28] * mdiggory (~mdiggory@64.50.88.162.ptr.us.xo.net) Quit (Quit: mdiggory)
[22:35] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[23:18] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[23:49] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.