Repository configuration (e.g. repository.json): should this be standardized in any way or do different Fedora implementations use whatever configuration style/content that makes sense for the implementation?

An RdfSource that is not a NonRdfSourceDescription currently describes itself. Should that be reflected in the Java API?

repository.json - standardize it? Aaron Coburn – repository.json file is currently passed right into modeshape. Do we want to put a fedora stamp on it and standardize it or just leave it up to the implementations. After some more thinking Aaron Coburn thinks we should just leave it up to whatever the impl wants to do. Esmé Cowles agrees. If there is a use-case where there are files on a system, we may want to do something like this, but in general we should leave it up to the implementations.

general idea of not printing stack traces. Esmé Cowles thinks developing a style for this would be a nice thing to do.

general idea is yes - it's a good idea, but idea of what it is and how implemented would need to be thought through.

Deprecation of file system federation

Esmé Cowles and Mike Durbin - two who initially wrote code and had use cases for it. Because you can't edit it with REST API it's read only. You can use it to store files, but you can use it to store metadata usefully. Linking is the same as if things were on an external webserver. If you have files you want to serve from disk, then you should use a webserver. You can link to them using the same external content approach. Why should we keep federation, given that?

Kate Lynch - they use it in the infrastructure of repo currently being developed. Interested in exploring the possibility of them maintaining it if it were to become an external feature.

tried turning off federation and then used external system. Alt is to put files into Fedora directly. W/o connector you can't do the file system pattern w/in fedora. If that's what's needed then you need to figure out another way.

Explore using a regular webserver in this scenario to see if it meets needs. If not, explain use case and we can discuss again.

There is a bug with federation in modeshape 5 that prevents federation from seeing new files when Fedora's running.

Reason for federation - the file system is a remote cloud base location. File system source of metadata, then redirect

One path is move to external modules and have it be a plugin from there. It could be maintained separately.

Is there anyone else outside who might be using federation feature? Might be worth asking around to see who might be using it. Wouldn't want to be a roadblock for people to upgrade.

Who is using it (maybe):

U. of Virginia

Cleveland Museum of Arts – not sure if they are actually using it.

Suggestion is to broadcast this more loudly to ensure that the broader community knows about it and has a chance to see how it might effect their infrastructure. The group is planning on doing this.

4.6 release scheduleBill Branan - Hydra In a Box is curious about the schedule.

Trying to balance the next Hydra release based on when Fedora next releases.

How fedora module dependency chain works. The Fedora Http module depends on modeshape module - modeshape module could be entirely pluggable. There is a pull request that takes this part way. A user of Fedora wouldn't notice a difference, but the code would be differently organized.

Import/export endpoints taken out. There is currently a notice about how it will be removed in 4.6. It's very JCR specific.

Are the endpoints necessary for upgrade to Modeshape5? The endpoints could be part of an external module to access it for the upgrade.

This hasn't been discussed a whole lot yet.

How messages are serialized - the current format is a JMS message. At some point it would be nice if Fedora supported more then just JMS, so a standard format would need to exist. Currently is a header only format. The header of the property of what's changed in Fedora is wrong and hard to make work correctly. It would be good to get consensus on what that serialization should be.

We should change this as soon as possible so that people who are writing code against this don't get too far in the process and have to change a bunch of things. All of the currently camel tools will need to be updated.

Aaron Coburn created a proposal (agenda item 8 from above) of what messaging could look like.

Will 4.6 include Modeshape 5.X? Probably not 5.0, but if 5.1 is actually released on July13 – we could have release in August. That seems pretty far off, though.

Talked about removing JCR endpoints - fcr import/export - trying to move JCR specific features from core. Move them to extension module. Still be available, probably web-app plus, but not in the core anymore. fcrepo-serialization module would be part of this change and moved to extension. Moving JCR ones out is great. Esmé Cowles raised considerations about migration - there maybe be concerns, but if it's in webapp plus and most use that, then this may not be an issue.

Maybe leave them there, but have them be Spring injected - could wire in JCR serialization or some future (maybe RDF) serialization. Esmé Cowles thinks this is the right way to more forward.

LDP Client available? More about the java client - there have been a few written for Fedora. The current one we have is pretty basic. Now some people are using it and are interested in having it be a bit smarter. Do you rewrite it or do you extend it to make it more sophisticated - or- do you find an LDP client that exists on which we can base this Fedora client. Esmé Cowles - There are a number of clients that are paired with other LDP implementations and not transferable. A generic java LDP client would be great or to talk to marmotta or others with existing client and maybe see if one of those could be generalized to work with more then one server. Aaron Coburn looked at a few projects and it seems that many of them are tied to a specific framework. OSGi dependencies can make this challenging. Maybe just revamp java client

multi-tenancy - Bill Branan - hydra in a box wants to use fedora in a way that allows multi-tenant apps sitting on top of fedora.

would like single fedora to scale out with cloud storage underneath. Currently thinking (writing?) Modeshape binary store for S3

make calls through fedora to potentially multiple tenants. Had talked to Andrew Woods regarding Modeshape workspaces to divide tenants

Question – should you be able to make links from one tentant to another? Not expecting to at ths point. One root node for each tentant

Question - binary store hierarchical tree currently based on sha1 . Would content from tenant a be completely separated from tenant b? Content from tenant a goes in one S3 bucket and tenant b in another S3 bucket. Would like the opportunity to put it in a totally separate AWS account. Keep the content separate and not intermixed at all.

Question - any links to S3 modeshape documentation? Has github repo that they just started -

There is a ticket in modeshape to create this, but was closed as nofix. Bill Branan will talk to them more about it.

If anyone has thoughts on S3 or multi-tenancy please get in touch with Bill Branan.