Time/Place
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
- International toll free: http://www.readytalk.com/intl
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
- Once on the call, enter participant code 2257295
- IRC:
- Join the #duraspace-ff chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #duraspace-ff on irc.freenode.net
Attendees
- David Wilcox
- Unknown User (escowles@ucsd.edu)
- Eric James
- Ed Fugikawa
- Yinlin Chen
- Kevin S. Clarke
- Giulia Hill
- Stefano Cossu
- Betsy Coleman
Agenda
- Release status: 3.8.0
- Release status: 4.0 beta 2
- Java client API
Minutes
- Fedora 3.8.0
- Last Fedora 3.x release
- Testing is ongoing
- A couple small issues but nothing that will significantly delay the release
- Oracle/Windows issues
- Ed: How does Fedora 3.8.0 work with Hydra/Islandora?
- Should be fully compatible
- Esme will follow up with Scott
- Part of the testing includes tests against Hydra/Islandora
- Fedora 4.0 beta 2
- Released last night by Michael Durbin
- On GitHub now
- ModeShape 4.0-alpha included
- Java client API
- Core Java client API design/implementation done last sprint
- Creating/retrieving objects, etc.
- Nearly at a point where anyone could implement a small service
- Betsy: Question about LDP clients
- None were good fits
- Esme: Most clients listed in W3C inventory were client/server combos that worked with each other
- Servers followed some parts of LDP but also added on
- Clients were tightly coupled with servers and their features
- We are in a similar position - we will also have a server/client that follows the LDP spec but also includes features unique to Fedora 4
- Still interested in finding a good generic client that supports more than one server
- Core Java client API design/implementation done last sprint
- Stefano: ModeShape 4.0-alpha
- Why switch to alpha?
- Lots of bugs around performance and file federation, targeted to be fixed in next beta
- Wanted to get the move to ModeShape4-alpha out of the way so we can quickly move to ModeShape4-beta
- The ModeShape beta will be released in time for the Fedora 4.0 production release later this year
- ModeShape working on issue of having many children under a single node
- Currently we deal with this using the hierarchy mapping, which would no longer be necessary
