Log of the #duraspace-ff channel on chat.freenode.net

Using timezone: Eastern Standard Time
* allupaku joins05:14
* allupkau joins05:16
* allupaku leaves
* allupkau leaves06:04
* allupkau joins06:05
* allupkau leaves06:41
* allupkau joins06:43
* escowles joins07:23
* allupkau leaves07:30
* escowles leaves07:53
* dwilcox joins07:55
* escowles joins07:58
* escowles leaves08:08
* escowles joins08:10
* escowles leaves08:45
* bsc joins09:05
* bsc leaves09:06
* Fulgen joins09:11
* escowles joins09:18
* mohamed joins09:27
* ksclarke joins09:45
* ermadmix joins09:48
<pivotal-bot>Andrew Woods added "Create XACMLAuthorizationDelegate Unit Test" https://www.pivotaltracker.com/story/show/7477487409:55
Andrew Woods edited "Create XACMLAuthorizationDelegate Unit Test" https://www.pivotaltracker.com/story/show/7477487409:56
Andrew Woods added "Create PDPFactory Unit Test" https://www.pivotaltracker.com/story/show/7477496009:57
Andrew Woods edited "Create PDPFactory Unit Test" https://www.pivotaltracker.com/story/show/74774960
* edInCo joins
<pivotal-bot>Andrew Woods added "Bonus below -----------------------" https://www.pivotaltracker.com/story/show/74774994
Andrew Woods edited "Bonus below -----------------------" https://www.pivotaltracker.com/story/show/74774994
* mikeAtUVa joins09:59
* github-ff joins
[fcrepo4] escowles created federation-errors (+2 new commits): http://git.io/MQ2MYw
fcrepo4/federation-errors b0014a3 Esmé Cowles: Handling extraproperties storage that can't be read or written
fcrepo4/federation-errors 56c795a Esmé Cowles: Updating federated filesystem directories timestamp when their child resources change
* github-ff leaves
<awoods>Hello All.10:00
This is the scheduled time for the Fedora Java Client Library discussion.10:01
We are limited to one hour, then the regular Fedora Committers call directly follows
* betsysc joins10:02
<awoods>Konrad has been leading this java-client-library effort... but I do not see him in this channel
<escowles>awoods: that's too bad -- can anybody ping him on twitter, IM, etc.?10:03
<awoods>escowles: maybe email
can you do that, escowles?10:04
In the meantime, are there any suggested updates to the agenda?
<escowles>yep, email sent
<awoods>let's give Konrad a minute or two, then we can jump into the requirements.10:05
<escowles>awoods: i think it goes under b. Approach, but i think how we evaluate LDP libraries is very important
<awoods>escowles: agreed10:06
escowles: A few LDP Java client options are listed here: https://www.w3.org/wiki/LDP_Implementations
It appears that Konrad has done some initial evaluation, but the process is unclear10:07
A draft list has been posted: https://wiki.duraspace.org/display/FF/Design+-+Java+Client+Library10:08
Shall we first can discuss these?
Shall we first discuss these?
* KonradEichstaedt joins
hi there10:09
<awoods>welcome KonradEichstaedt
We were just beginning the discussion of requirements
starting with the draft list you posted here: https://wiki.duraspace.org/display/FF/Design+-+Java+Client+Library
KonradEichstaedt: Would you like to walk us through them?10:10
<escowles>on the design page, i see the indexing and ingest requirements that i added, but i don't see any others
<KonradEichstaedt>is this time also a call available
<awoods>Others: please be coming up with other requirements
KonradEichstaedt: we can open the regular Fedora committers phone line, if that would be easier.10:11
escowles: Yes, those are the requirements I see.10:12
<KonradEichstaedt>no it's ok from my point of view
<awoods>escowles: would you be interested in walking us through them?
<escowles>awoods: sure
basically the use cases i have for the client are the (already existing) indexer and batch ingest10:13
the indexer has custom java code to retrieve object metadata for indexing, and walking the three of resources to reindex everything
the batch ingest is a little fuzzier, but basically creating objects, loading metadata and files based on content on disk, and presumably from fcrepo3 eventually10:14
i remember someone saying we should support the same functionality as the fedora3 java client, but i'm not familiar with that to know what that means
<awoods>escowles: It sounds like you are presenting use-case based requirements10:15
i.e. indexing and batch ingest10:16
<KonradEichstaedt>did you check the
to the client library ?
* longshou joins
<escowles>KonradEichstaedt: i did look at it briefly, but didn't dig into the source code to figure out what it can do beyond what's in the README10:17
<awoods>escowles: in terms of the requirements on the java-client, do you have specifics of what you would want the library to look like?
<KonradEichstaedt>we using this to manage repository based on an javaee application (our own manager)
<awoods>escowles: It seems like we want a general/generic client-library, over which your indexing and batch ingest logic would sit.10:18
<KonradEichstaedt>escwoles: your are interested in authentification?
<escowles>awoods: right -- i was detailing my use cases so we would know what kind of capabilities the library would have
<awoods>escowles: ok10:19
<escowles>KonradEichstaedt: no, we don't do authentication in the repository -- we just use PREMIS-style rights metadata, and then enforce that in our Hydra frontend
<awoods>I was also viewing requirements from the perspective of the existing F4 REST API.
It seems logical to wrap the existing REST API with "easy to use" Java classes10:20
The REST API supports actions on Resources:
# Objects
# Binary content
# Batch operations
# Export/Import
# Locking
# Versioning
The REST API also supports actions on Services:10:21
# Access roles
# Backup/Restore
# Fixity
# Identifiers
# Namespaces
# Node types
# Search - properties text
# Search - sparql
# Sitemaps
# Transactions
# Transform
# Workspaces
<escowles>awoods: yes, wrapping the REST API with Java classes seems like a good approach
<KonradEichstaedt>that sounds great from my point of view
<escowles>those classes would probably wind up looking pretty similar to some of the kernel classes
<awoods>escowles: yes. And one option would be to have those new client classes implement the same interfaces as the kernel classes. So theoretically we could write business logic that could talk to an interface that may be remote or local.10:23
Although, it may be cleaner to have the new classes designed differently.10:24
<KonradEichstaedt>awoods : do you know the fedora3 mediashelf library ?10:25
<escowles>awoods: right -- implementing those same interfaces would be nice, but not as high a priority as having a good design, functionality, etc.
<awoods>KonradEichstaedt: I know of it, and am familiar with the general approach.10:26
escowles: agreed
In terms of requirements, is it as simple as "support the wrapping of existing REST API"?10:27
...with some use-cases that keep it sane?10:28
<pivotal-bot>Longshou Situ added comment: "I think returning with a forbidden status does look good for deleting a not assigned property. But the mes..." https://www.pivotaltracker.com/story/show/72805066
* awoods waiting
<escowles>awoods: yes, that sounds like a good feature set to shoot for -- but what about prioritization?
do we implement sitemaps or locking first? etc.10:29
<awoods>escowles: sure, let's agree on the first set.
Then we can move on the "Approach"10:30
Then we can move on to "Approach"
<escowles>when i look at the list of resource and services above, i see the resource Object and Content, and the services of fixity, identifiers, namespaces, node types as the core things i need for my use cases10:31
* KonradEichstaedt leaves
<escowles>and probably transform for the solr indexer
<awoods>so: # Objects10:32
# Binary content
# Fixity
# Identifiers
# Namespaces
# Node types
# Transform
opinions? +1/-110:33
looks like we lost KonradEichstaedt ...
fwiw, I like the list: +1
* KonradEichstaedt joins
<awoods>others? opinions?10:35
<KonradEichstaedt>my connction was gone
<escowles>KonradEichstaedt: we just listed a "core" set of REST API functionality to support as a starting point:
Objects, Binary content, Fixity, Identifiers, Namespaces, Node types, Transform10:36
* ermadmix leaves
<KonradEichstaedt>escowles ok thanks for take me
<gregjansen>hey y'all, can it support connection pooling?
<awoods>gregjansen: sounds like a reasonable requirement10:37
<escowles>gregjansen: that sounds reasonable -- easy to implement in httpclient
<awoods>I am not sure two +1's are consensus10:38
* awoods thinking three is better than two10:39
<escowles>i'd be interested in hearing about how other people expect to use the client
<betsysc>we are primarily looking at using it for handling batch ingest
* mikeAtUVa would use it in his ingest scripts and tools that interact with the repository.
<Fulgen>batch ingest here as well10:40
* gregjansen would write code faster, without having to constantly look up the REST API calls.
<escowles>mikeAtUVa: do you have tools that need any other features? versioning? export?
<mikeAtUVa>escowles: almost certainly, but I'm most interested in having a central client code base so that when I need to write client code to do those things it doesn't get lost in a locally maintained SVN repository or something;)10:41
escowles: I'm not so much concerned about which features other people write
<KonradEichstaedt>we are interested in managing our next projects (30 million digital chinese objects ) using the fedora4 + our own managing tool for basic operation10:42
* gregjansen wants to write batch ingests and also use it to integrate repo with curator's workbench10:43
<escowles>KonradEichstaedt: so that sounds like a broader set of use cases -- is there anything not on the list above that you think is essential?
<KonradEichstaedt>ingest / search / creating based on licensing information access rules
no for the first time its ok
<awoods>KonradEichstaedt: "creating based on licensing information access rules"?10:44
<KonradEichstaedt>our project will start this year and iam in preparation at the moment
<escowles>it sounds like we're in agreement that getting started is more important than getting all the features we want, so maybe we should move on to approach?10:45
<gregjansen>use it to write "microservices" that enhance repo data
<awoods>It sounds like the proposed list covers the bases, and it is not *too* broad.
- LDP client at the core10:46
- Fedora logic over LDP client
<KonradEichstaedt>I started trying this today, ... it sound good from my point of view10:47
<awoods>This is assuming the LDP client handles the connection details.
KonradEichstaedt: what criteria were you using to evaluate the LDP clients?10:48
While KonradEichstaedt is pondering, how should be move this process forward... more quickly.
<KonradEichstaedt>i just started today writing a skeleton and looked how easy it is to use the library10:49
<awoods>While KonradEichstaedt is pondering, how should we move this process forward... more quickly.
* ermadmix joins
* scossu joins10:50
<escowles>awoods: it seems like getting the skeleton up and publicly available would be a good next step -- it would be good if people could start trying this out with a shared github repo, etc.10:51
<awoods>escowles: agreed
I think it would be great if we:
- Evaluated and agreed on an LDP clients
- Designed interfaces for the fedora-java-client-library
- Divided implementation responsibilities for the interface impls
- Meet regularly (every two weeks?)
- Defined deliverables for each meeting
<escowles>awoods: would the weekly committers call be a good forum for checking in on this -- or do we need more time than that10:52
<awoods>escowles: It makes sense to use a portion of the Thursday calls, yes.10:53
I would like to initially see agreement on an LDP client
<KonradEichstaedt>may be we can start with two weeks and if we are in flow we can go to weekly
<awoods>But we can also define interfaces in parallel to the selection of an LDP client10:54
KonradEichstaedt: I am ok with dedicating a portion of every-other committer call to discussing the java-client-library.
speaking of which, shall we transition this conversation onto that line, now?10:55
<escowles>awoods: yes, we can look at the existing kernel interfaces now and seeing if there are any issues with using them or closely adapting them
awoods: sounds like a good plan10:56
<KonradEichstaedt>awoods ok
* scossu1 joins
<awoods>Let's take the first half of the committers call to wrap this discussion up: https://wiki.duraspace.org/display/FF/2014-07-10+-+Fedora+Committer+Meeting
* scossu leaves10:57
* edInCo leaves11:00
* betsysc leaves
* osmandin joins11:04
* skenny joins
<awoods>escowles: https://github.com/fcrepo4-labs/fcrepo4-client11:15
* mohamed leaves11:25
* mohamed joins11:31
<osmandin>button doesn't seem to work11:41
* nikhiltri joins
* edInCo joins11:54
* skenny leaves12:01
* osmandin leaves12:05
* github-ff joins12:10
[fcrepo-jms-indexer-pluggable] lsitu opened pull request #47: Implementation for no binary content jcr/xml file system persistence. (master...feature/jcrxml_persistence) http://git.io/pTNaCw
* github-ff leaves
<pivotal-bot>Longshou Situ added comment: "https://github.com/fcrepo4/fcrepo-jms-indexer-pluggable/pull/47" https://www.pivotaltracker.com/story/show/7470201012:11
Longshou Situ finished "Persist jcr/xml to file system" https://www.pivotaltracker.com/story/show/7470201012:13
* longshou leaves12:17
* gregjansen1 joins12:51
* gregjansen leaves12:53
* longshou joins13:01
<pivotal-bot>Longshou Situ added comment: "@awoods13:37
I see that the message from the backend to delete the not assigned registered node type as myns:m..." https://www.pivotaltracker.com/story/show/72805066
Longshou Situ started "Update fcr:sparql requests with a form" https://www.pivotaltracker.com/story/show/7261922813:38
* github-ff joins13:42
[fcrepo4] escowles created federation-lastmod (+1 new commit): http://git.io/2E6YPQ
fcrepo4/federation-lastmod b498f01 Esmé Cowles: Updating federated filesystem directories timestamp when their child resources change
* github-ff leaves
* ermadmix leaves
<pivotal-bot>Esme Cowles started "Phantom federated directories" https://www.pivotaltracker.com/story/show/7098999213:50
Esme Cowles added comment: "https://github.com/fcrepo4/fcrepo4/pull/411" https://www.pivotaltracker.com/story/show/7098999213:51
* github-ff joins
[fcrepo4] escowles opened pull request #411: Updating federated directory timestamps when their child resources change (master...federation-lastmod) http://git.io/gnqOjw
* github-ff leaves
<pivotal-bot>Esme Cowles finished "Phantom federated directories" https://www.pivotaltracker.com/story/show/7098999213:52
* ermadmix joins13:53
* github-ff joins13:54
[fcrepo4] escowles force-pushed federation-errors from 56c795a to b0014a3: http://git.io/0yciaw
* github-ff leaves
<pivotal-bot>Mohamed Mohideen Abdul Rasheed started "Create XACMLAuthorizationDelegate Unit Test" https://www.pivotaltracker.com/story/show/7477487414:00
* gregjansen1 leaves14:53
<pivotal-bot>Andrew Woods added comment: "Returning the exception you found seems clear: ""15:19
javax.jcr.nodetype.NoSuchNodeTypeException: "myns:mymixin" i..." https://www.pivotaltracker.com/story/show/72805066
Mohamed Mohideen Abdul Rasheed added comment: "Added documentation: https://wiki.duraspace.org/display/FF/Response+Time+Comparison+of+Si..." https://www.pivotaltracker.com/story/show/7455981015:21
Mohamed Mohideen Abdul Rasheed finished "Cluster: Read load balancing" https://www.pivotaltracker.com/story/show/74559810
Longshou Situ added comment: "I think either 403 or 404 should be fine, but 404 seems more easy to understand for non-tech guys. The cur..." https://www.pivotaltracker.com/story/show/7280506615:41
Scott Prater added comment: "@awoods @longshous : looks good. I now see when I submit my (invalid) query the following 500 error: "or..." https://www.pivotaltracker.com/story/show/7107390415:46
Scott Prater accepted "NPE when submitting SPARQL query with FILTER" https://www.pivotaltracker.com/story/show/71073904
Andrew Woods added comment: "Thanks, @scottprater " https://www.pivotaltracker.com/story/show/7107390415:47
* gregjansen joins16:07
* gregjansen leaves16:08
* dwilcox leaves16:28
* mikeAtUVa leaves17:07
* scossu1 leaves18:08
* ksclarke leaves18:23
* longshou leaves18:32
* edInCo leaves
* cbeer leaves18:33
* pivotal-bot leaves
* longshou joins
* edInCo joins18:35
* cbeer joins18:36
* pivotal-bot joins
* ermadmix leaves18:37
* scossu joins18:52
* nikhiltri leaves18:54
* scossu leaves18:57
* ermadmix joins18:58
* ermadmix leaves19:29
* mohamed leaves19:40
* mohamed joins19:41
* edInCo leaves
* mohamed leaves19:42
* ermadmix joins19:59
* escowles leaves20:19
* escowles joins20:20
<pivotal-bot>Andrew Woods added comment: "Pending code review comments." https://www.pivotaltracker.com/story/show/7470115620:22
Andrew Woods rejected "Export jcr/xml with no binary content for file system persistency." https://www.pivotaltracker.com/story/show/74701156
* ermadmix leaves20:31
* ermadmix joins21:20
* cbeer leaves21:27
* pivotal-bot leaves
* longshou leaves
* Jotudin_ leaves
* awoods leaves
* benpennell leaves
* KonradEichstaedt leaves21:28
* Fulgen leaves
* ermadmix leaves
* escowles leaves21:35
* benpennell joins21:53
* awoods joins
* scossu joins21:59
* pivotal-bot joins
* cbeer joins
* Jotudin_ joins
* scossu leaves22:07
* ermadmix joins
* KonradEichstaedt joins22:10
* Fulgen joins
* ermadmix leaves23:13
* ksclarke joins
* longshou joins23:24

Generated by Sualtam