Rewrite TCP / UDP binding

[GoogleCodeExporter]

Although the current TCP binding is a nice intellectual exercise in terms of 
combining underlying connection-oriented and connection-less sockets into a 
unified base class, from which a TCP and UDP binding are derived, I propose to 
rewrite my own code so that
 - TCP and UDP bindings are completely seperate, in order to better handle specific TCP and UDP connection flows
 - Remove the multiplexing nature (e.g. more than 1 Item definition can use the same host:port socket to send data) and move to a "1 Item -> 1 SocketChannel" model
 - Improve underlying javio.io exception handling
 - Make the bindings more configurable (# connection attempts,...)
 - Improve the "demo" TCP binding to better handle common use-cases (e.g. cfr forum discussion for Raspberry Pi etc)

This one can be auto-assigned to me ;-)

Original issue reported on code.google.com by karel.go...@gmail.com on 21 Aug 2013 at 2:49

[GoogleCodeExporter]

Transformation services should also be possible to use with TCP/UDP binding.

Original comment by pauli.an...@gmail.com on 21 Aug 2013 at 6:11

[GoogleCodeExporter]

Pauli,

Transformation in thesen of accepting Regex in the item definitions, or doing 
XSLT ? I am not an expert in XSLT will do a brave copy/paste from another 
binding that supports this ;-)

Original comment by karel.go...@gmail.com on 22 Aug 2013 at 8:13

[GoogleCodeExporter]

I meen transformation for tcp/udp data by xslt/xpath/regex rules, like it's 
possible e.g. on exec or http binding. 

Actually, I planned to add transformation service support to current tcp 
binding implementation, but I postponed it because I don't needed anymore. 

Original comment by pauli.an...@gmail.com on 22 Aug 2013 at 1:11

[GoogleCodeExporter]

Kai or Thomas,
the new binding is ready for review/inclusion in my clone.

Wiki has to be rewritten still, as some semantics have changed; tried to take 
into account all demands from the community but doing so this binding is 
becoming a nasty complex thing to understand though.

Original comment by karel.go...@gmail.com on 17 Sep 2013 at 2:45

[GoogleCodeExporter]

Original comment by kai.openhab on 17 Sep 2013 at 5:41

• Changed state: ReadyForReview
• Added labels: Version-1.4.0

[GoogleCodeExporter]

Just a remark:

The TCP binding requires Java 7 (AbstractDatagramChannelBinding calls methods 
on InetSocketAddress, that are not public in Java 6, but are public in Java 7).

The bundle itself does not specify an execution environment (which should be 
"JavaSE 1.7"), but only uses the workspace default JRE. So the project cannot 
be compiled unless Java 7 is the workspace default JRE.

The Hardware FAQ (https://code.google.com/p/openhab/wiki/HardwareFAQ) mentions, 
that Java 6 is required to run the project. This is not correct, as Java 7 is 
required.

IMHO every single bundle should use an execution environment instead of the 
workspace default JRE. So this problem is not just related to this tcp binding, 
it is a global problem. However, the tcp binding is the one that shows 
compilation errors without Java 7.

Regards,
Martin

Original comment by planetre...@gmail.com on 18 Oct 2013 at 8:18

[GoogleCodeExporter]

Original comment by teichsta on 5 Nov 2013 at 10:53

• Added labels: To-Github

[GoogleCodeExporter]

This issue has been migrated to Github. If this issue id is greater than103 its 
id has been preserved on Github. You can open your issue by calling the URL 
https://github.com/openhab/openhab/issues/<issueid>. Issues with ids less or 
equal 103 new ids were created.

Original comment by teichsta on 17 Nov 2013 at 8:08

• Added labels: Migrated-To-Github

[GoogleCodeExporter]

see above!

Issue has been migrated to Github and should be discussed there.

Original comment by teichsta on 21 Nov 2013 at 1:51

• Changed state: Invalid