search

IBMStreams / administration

Umbrella project for the IBMStreams organization. This project will be used for the management of the individual projects within the IBMStreams organization.
Other
19 stars 10 forks source link

Propsal: Split Internet toolkit into base and extended toolkit #113

Closed joergboe closed 6 years ago

joergboe commented 7 years ago

Proposal

As it has been internally discussed the Internet toolkit should be split into a base toolkit and an extended toolkit. The goal is to separate all operators with an integrated web-server function from all other operators and functions.

The internet base toolkit

shall have all classical (sink and source) operators without the web-server functionality. Name: streamsx.inet
namespaces: com.ibm.streamsx.inet / com.ibm.streamsx.inet.http / com.ibm.streamsx.inet.ftp Artifacts:

The extended internet toolkit

shall include all operators with the embedded web-server: Name: streamsx.inetext namespaces: com.ibm.streamsx.inetext.rest / com.ibm.streamsx.inetext.wsserver Operators:

ddebrunner commented 7 years ago

@joergboe It's a general point that the overall SPLDOC for a toolkit may contain references between operators, namespaces etc. Thus removing or cherry-picking operators may cause dangling references in the remaining SPLDOC. Thus it may not be trival to try to subset a toolkit. Though I'm not sure anyone wants to do that anymore.

ddebrunner commented 7 years ago

@chanskw

I'll ditto @ejpring 's vote.

joergboe commented 7 years ago

yes, if there are references between operators in the documentation then there is a problem. but I would expect that a simple run of spl-make-doc complains about that. If not, then we have to check the docu

mikespicer commented 7 years ago

We had a call on this and agreed that there is no strong objection to the proposal that Samantha made but also a recognition that it does not solve the real problem of having toolkits with both product level and non-product level code that could become more common.

Gert has been given the authority to make a decision on whether he thinks its worth spending time on the split as agreed to in this thread (streamsx.inet.server toolkit in the same streamsx.inet repository) or to focus on other things.

Also the team have been asked to determine the right strategic solution for handling toolkits that have both product and non-product code. This is not a trivial problem and may require product changes. Having a build or branching strategy to selectively include components still has an issue with how the product vs full toolkit variants get versioned. Personally I still like the idea of being able to annotate capabilities as experimental (and also deprecated) and just having a single toolkit build and version strategy that includes all function in the toolkit, but the team should research options and make a proposal as they see fit.

chanskw commented 7 years ago

I will ditto @ejpring vote too.

chanskw commented 6 years ago

Closing this one.