Proposal: streamsx.httpasync

[leongor]

Following this issue I suggest to create a dedicated toolkit for HTTPRequestAsync operator. There was an attempt to contribute this operator to streamsx.inet toolkit, but it seems that it's not easy to integrate them. streamsx.inet toolkit is mostly java based and expects always to be built from the scratch using ant/maven. streamsx.httpasync is a pure c++ toolkit based on once build / run ready approach.

[apyasic]

+1

[mikespicer]

The issues raised in the pull request to deliver the c== operator referenced above of platform availability and legal approval do not go away with a separate toolkit.

I did not see a response on why we are not adding an async option to the existing java operator can you please explain the rationale.

[joergboe]

There is more than one possibility to solve the async operators requirement based on the existing and widely used technologies:

1. Use the streams primitives (UDP + queue)
2. Extend the java operators as mike proposed
3. Implement a C++ primitve operator using a widely used http lib

[leongor]

@mikespicer

The issues raised in the pull request to deliver the c== operator referenced above of platform availability and legal approval do not go away with a separate toolkit.

Right - never said otherwise.

I did not see a response on why we are not adding an async option to the existing java operator can you please explain the rationale.

I propose to contribute the ready http async operator that is based on the work we did in our previous engagement. If someone wants to extend the existing java operator - I have no objection.

[leongor]

There is more than one possibility to solve the async operators requirement based on the existing and widely used technologies:

Use the streams primitives (UDP + queue)

If you mean to implement the whole http stack with SPL code - good luck with that.

Extend the java operators as mike proposed

Look at my answer to @mikespicer

Implement a C++ primitve operator using a widely used http lib

That what is done here.

[Yifat-Yulevich]

+1 Async, none blocking capability is essential and required for Streaming pipelines for immediate use. As this was already developed in previous engagements, and it is stable - we can open this and handle the licensing issues.

[joergboe]

If you mean to implement the whole http stack with SPL code - good luck with that. The internet toolkit has functions that implement the http operations (and use the libcurl). Of course we should use these functions

[leongor]

But then you're going to have a sync, not an async.

[joergboe]

As discussed in HTTPRequestAsync there are issues with the used library and we can not support this for all platforms that streams support. On the other hand I do not want to block this contribution with this usage of an emerging and innovative library. So I would propose to include the operator into the inet toolkit repository but into an different directory/toolkit.

[leongor]

+1

[leongor]

Closing the issue - continuing here.