Client http library?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Client http library?

jewzaam
Administrator
We have stayed away from client libraries but I see them forming and there is value in having client libraries that make things easier.  Specifically:
* SSL
* cert auth

In lightblue-applications repo there is code for both.  What about pulling this out to a separate repo (so it's not tied to our management applications) and make it usable by any client?  There's a good bit of work put into these to make it work, it would be great to not have to reproduce it for each client.  The risk is having shared utility classes, something we've had lots of pain with in the past.

Naveen
Reply | Threaded
Open this post in threaded view
|

Re: Client http library?

jewzaam
Administrator
Talked in scrum this morning and decided to create a repo for clients simply named lightblue-client (or should it be plural?).  The package would then be com.redhat.lightblue.client with the simple http client (SSL and/or client cert support) being in package com.redhat.lightblue.client.http or some such.

The secant repo is for a more complicated project intented to bridge json to pojo and back for java applications.  It could use the simple http client for communication on the back-end.
Reply | Threaded
Open this post in threaded view
|

Re: Client http library?

dhaynes
A new repo has been created (https://github.com/lightblue-platform/lightblue-client) and the initial version of the client stuff we've done for metadata management has been checked in.  Waiting on completion of publish permission request from Sonatype to configure Travis/Coveralls/etc.