Feature spec: HTTP Server extension for generic REST interfaces

[rdumusc]

I've tried to gather the requirements that we identified during our work on Tide html interface and propose an implementation. See formatted version here.

For those interested, some more thoughts about ZeroEQ / REST in this internal document. It is not include here as it does not fit the feature spec format.

[rdumusc]

@ppodhajski FYI, can't add you to the list of reviewers (?)

[eile]

@rdumusc : @ppodhajski was not part of this org. Invitation sent.

[ppodhajski]

Stefam, I think you invited me again to BlueBrain instead of HBPVIS.

2017-02-12 14:59 GMT+01:00 Stefan Eilemann notifications@github.com:

@rdumusc https://github.com/rdumusc : @ppodhajski https://github.com/ppodhajski was not part of this org. Invitation sent.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/HBPVIS/ZeroEQ/pull/200#issuecomment-279220314, or mute the thread https://github.com/notifications/unsubscribe-auth/AS6xo6JVUe6y5bQSeBPvp_i3IHtufuDDks5rbxAogaJpZM4L9ghu .

[eile]

Nope:

[eile]

I vote for option 1:

• It is simpler
• It has a clear separation of responsibities (App threading is managed by app if needed, allows for any model the app wants)
• Multithreading cppnetlib can still be done (with one single queue cppnetlib-main)

[hernando]

Option 1 is deferring the problem for later and makes the code more verbose for the client in any situation, even if you don't care about asynchronous requests, which I'm not sure is necessarily better. But I wont' oppose that resolution.

[eile]

Which problem is deferred to later?

[eile]

For synchronous request we can have syntactic sugar to wrap the function result in a ready future, which we'll have for the legacy API anyhow.

[hernando]

It defers the threading, despite cppnetlib already has it's own solution and the implementation will need to change anyway, but not a big deal.

A thought that has just come to my mind is that something that needs to be verified for an efficient implementation to work with a single cppnetlib thread is whether it's possible to wait on multiple futures and file descriptors and the same time. This may be easier to implement if the implementation doesn't have to deal with std::futures but can use whatever synchronization mechanisms cppnetlib provides, which is only possible with option 2.

[rdumusc]

So based on offline discussion, I am merging this proposition as it is. Unless there are more comments, we will use the first proposition as a base for doing the implementation.