Different api by client transport providers

[RafaelKa]

PawlTransportProvider

    /**
     * Constructor
     *
     * @param string $URL
     */
    function __construct($URL = "ws://127.0.0.1:8080/")
    {
        $this->URL     = $URL;
    }

and RawSocketClientTransportProvider

    /**
     * Constructor
     *
     * @param string $address
     * @param int $port
     */
    function __construct($address = "127.0.0.1", $port = 8181)
    {
        $this->address   = $address;
        $this->port      = $port;
        $this->transport = null;
    }

have different constructors.

I would like to provide a PR for united API but i'm not sure which way is preferred by community.

Please note, that react/socket-client provides tls and UDS connections
as well ratchet/pawl provides secure web socket connection

So i think url way will be more robust:
for Pawl

'ws://domain_name_or_ip:port'
'wss://domain_name_or_ip:port'
'unix:///path_to_uds.sock' 

Not sure but Pawl seems to support currently unix:// as well, because it uses Connector::create() method from react/socket-client

for RawSocket

'tcp://domain_name_or_ip:port'
'tls://domain_name_or_ip:port'
'unix:///path_to_uds.sock'

Also i think that the RawSocketClientTransportProvider can be revised to give a way for similar api with Pawl.

PS: I provided PR for react/socket UDS support and psychoticmeow did similar for UDS but with BC break so if it is merged we can use UDS for router as well.

[davidwdan]

@RafaelKa different transport providers have different constructors because they can have different dependencies. I see your point about using a url, but I can see circumstances where you may have a transport provider without a url - like a serial port provider.

I think it's best to let each transport provider implementation define it's own requirements, instead of trying to shoehorn them into a format that might not be conducive to that transport.

[RafaelKa]

Why you can not define UART as URI?, just using comm://port_id;baudrate=9600;something=bla or comm://port_id?baudrate=9600&something=bla

With current API it is impossible to use UDS/TLS for RawSocket clients.
I think also, because RawSocket and Pawl providers using the same protocoll and same lib for low level layer ( also react/socket-client ), oth can get same API

[mbonneau]

Right now we are going to leave it up to the transports to decide what they need for construction. I would rather not develop new URI schemes as that is outside of the project scope. http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml