Time/Place
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:
- Time: 10:00am Eastern Daylight Time US (UTC-4)
- 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
- See IRC below
Agenda
- F4 Java Client Library (design page)
- Discussion of requirements
- Approach
- Distribution of tasks
Minutes
Actions and decisions were captured on the design page
From IRC
| <awoods> | Hello All. | 10:00 |
| This is the scheduled time for the Fedora Java Client Library discussion. | 10:01 | |
| https://wiki.duraspace.org/display/FF/2014-07-10+-+Special+Topic+Meeting+-+Java+Client+Library | ||
| We are limited to one hour, then the regular Fedora Committers call directly follows | ||
| <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: agreed | 10: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 unclear | 10:07 | |
| Requirements: | ||
| A draft list has been posted: https://wiki.duraspace.org/display/FF/Design+-+Java+Client+Library | 10:08 | |
| Shall we first can discuss these? | ||
| Shall we first discuss these? | ||
| hi there | 10: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 | |
| thanks, | ||
| <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 ingest | 10: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 eventually | 10: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 requirements | 10:15 |
| i.e. indexing and batch ingest | 10:16 | |
| <KonradEichstaedt> | did you check the | |
| link | ||
| to the client library ? | ||
| <KonradEichstaedt> | https://github.com/mediashelf/fedora-client | |
| <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 README | 10: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: ok | 10: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 | |
| <KonradEichstaedt> | ok | |
| <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 classes | 10: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 | |
| * 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. | |
| candidates? | ||
| 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 cases | 10:31 |
| * KonradEichstaedt leaves | ||
| <escowles> | and probably transform for the solr indexer | |
| <awoods> | so: # Objects | 10:32 |
| # Binary content | ||
| # Fixity | ||
| # Identifiers | ||
| # Namespaces | ||
| # Node types | ||
| # Transform | ||
| opinions? +1/-1 | 10:33 | |
| <escowles> | +1 | |
| looks like we lost KonradEichstaedt ... | ||
| <awoods> | yes | 10:34 |
| fwiw, I like the list: +1 | ||
| <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, Transform | 10:36 | |
| <KonradEichstaedt> | escowles ok thanks for take me | |
| <gregjansen> | hey y'all, can it support connection pooling? | |
| <awoods> | gregjansen: sounds like a reasonable requirement | 10:37 |
| <gregjansen> | sweet | |
| <escowles> | gregjansen: that sounds reasonable -- easy to implement in httpclient | |
| <awoods> | I am not sure two +1's are consensus | 10:38 |
| <gregjansen> | +1 | |
| heh | ||
| * awoods thinking three is better than two | 10: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 well | 10: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 operation | 10:42 |
| * gregjansen wants to write batch ingests and also use it to integrate repo with curator's workbench | 10: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. | |
| Approach: | ||
| - LDP client at the core | 10:46 | |
| - Fedora logic over LDP client | ||
| ? | ||
| <KonradEichstaedt> | I started trying this today, ... it sound good from my point of view | 10: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 library | 10:49 |
| <awoods> | While KonradEichstaedt is pondering, how should we move this process forward... more quickly. | |
| <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 that | 10: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 client | 10: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 plan | 10:56 | |
| <KonradEichstaedt> | awoods ok | |
| <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 | |
| <awoods> | escowles: https://github.com/fcrepo4-labs/fcrepo4-client | |
Actions
