clayborg added a comment.
In http://reviews.llvm.org/D14085#275507, @zturner wrote:
> I think most of the time they are used in a Connection class, but I don't
> think it's necessarily guaranteed they will always be that way.
>
> I can think of at least one use case in the future where we will need to open
> a socket to a server we don't control and stream some data down from the
> server. I don't see the advantage of using a Connection in that case.
Definitely not.
> So I would say: Right now it's probably always used in Connection, but I
> dont' want to lose the flexibility to use it standalone either.
Agreed. If they are mostly used in connection classes, I would say to do what
you said to do: add an enum and factory static method on Socket that uses that
enumeration and then make Connection class into plug-ins they themselves vend
the URL prefixes and instantiate a connection class with any arguments. So:
1 - convert Socket class to use enum + factory class:
enum class SocketType {
Tcp,
Udp,
UnixDomain
};
class SocketBase {
public:
static std::unique_ptr<SocketBase>
MakeSocket(SocketType type);
};
2 - Make Connection classes into plug-ins and have them parse the URLs in the
"static Connection *Connection::GetConnectionForURL(const char *url);"
> That said, IMO low-level OS primitive abstractions are by definition what
> Host is for, but higher level abstractions built on top of those can use the
> plugin interface
That is fine and the above two step solution would enforce that.
http://reviews.llvm.org/D14085
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
