I am making a project and for that i have to mention a protocol name for that.So I read about Wire Protocols used by Microsoft and Oracle, the thing is I need some names for wire protocol that i can use in postgres.
I had the same question. I would suggest the best "name" for the PostgreSQL wire protocol would be libpq, which is, of course, really just the name of the library used. I recall seeing other line protocols being called by their library APIs.
Related
I'm curious, is there a pre-existing protocol whose only requirement is that there be an init with no arguments? I'm creating a generic that needs to be able to initialize an associated type without worrying about any arguments. This seems to call for a protocol like this:
protocol HasEmptyInitializer {
init()
}
It seems like a pretty basic protocol that might be needed in many contexts. Before I go polluting my protocol space with the above, I was wondering if there is anything like that already in Foundation or other 1st party library. Does anyone know of such a thing?
This is a very famous non-protocol because it lacks semantics. For the background on why this is intentionally not a protocol in Swift, see Ole Begemann's writeup Protocols are more than Bags of Syntax. If you have a semantically meaningful protocol that only has this requirement, then there is no problem creating it, but it is quite rare.
The fundamental point of Ole's writeup (which gathers together many other conversations) is that a protocol is more than just "it has this method" (i.e. syntax). It's about what kinds of algorithms it facilitates. "Plusable" wouldn't be a good protocol to cover "things you can apply + to." What + means for Ints is not really the same as what + means for Collections (the latter isn't even commutative). Similarly, "makable by calling init()" tells you nothing about what the resulting object means. Is is "empty?" Some unspecified "default" value? Invalid? The semantics of protocols matter more than the syntax.
The zope.interface has (among many other things) run-time adapter registries, which allow to find suitable implementations of some interface at run-time.
Now, the python3.8 has structural subtyping support, but the question is: Are there any standard library mechanisms to achieve at least some primitive run-time adaptation out-of-the box? In other words, having some instance animal and an interface IFlying, is it possible to lookup an adapter for IFlying(animal)? Or is the typing.Protocol purely for typechecking?
The motivation of this question is: Does it make sense to continue using zope.interface in the new code, or will typing.Protocol make that obsolete soon (at least for simple adapter cases)?
I can see opinions like this, which hint that some standard interface support is there, but can't find concrete examples on how to replace adapter registry with Python3.8 or more recent standard library (short of writing some library on top of it).
Note: I am aware of What to use in replacement of an interface/protocol in python , but my question is specifically about how to make adaptation (and even multiadapters) possible.
I would like to describe services as components with their ports and interfaces. It should become clear by the description, what functionalities are provided, and how to utilize them.
In my understanding, I can type a port either with this notation <name>:<type>, where the type can be specified by an interface block? Or using the "lollipop", where the interface type is specified by the name of the "lollipop"?
Now, I would like to see what application or transportation protocol is utilized by a interface/port, to get an idea on how to connect to it. But I don't know what is the best way to do so. I thought about two ways.
First: specifying the protocol (here TCP/IP) by the port type and the interface (provided information) by the "lollipop" notation.
Second: specifying a transportation/application protocol as the base interface of an application specific interface.
I really don't know if any of that makes sense or if there is a better way to describe that. Please let me know.
EDIT:
Based on the answer of qwerty_so, I understand that the generalization of an interface from a protocol is wrong. But to indicate the utilized protocol, it should be specified by the port type? Based on that, I made another representation of two components (this time in UML, i hope it doesn't cause any confusion). Each component provides the same interface through a varied port. Basically it is the same as the first notation, extendet by the realize relation from the lollipop to the interface. The first component utilizes a basic TCP/IP and the second a gRPC protocol in order to realize the Interface1.
two components with different port types and same interface
Is that a more accurate way to represent the interface and its realization by a specific protocol?
Is the realize relation necessary, because shouldn't it be clear by the interface name?
TCP/IP is a protocol. And that's what is used for the port. Draw a realize relation from the port towards the interface.
The interface1 is the software interface. So draw a realize relation from the lollipop towards that.
Your lowest design would be wrong since interface and protocol are two very different things.
I always think of a port a a plug bundling a number of (SW) interfaces. In SysML terms it also extends to power supply as interface (which for pure soft-workers is kind of strange ;-).
I am pretty aware of the benefits of interfaces and how it helps aggregate common functionality of similar types of objects. However I believe people have taken this 'always program to an interface' a bit too far.
a) People starting off by ALWAYS defining an interface and then implementing it in a class even if that interface is too specific to be implemented by any other class. - Am I the only one who thinks that this serves no useful purpose?
b) Forcing all 'related' interfaces to derive for a common (useless) interface because it is now 'extendable' - What?
c) What do you do in scenarios where two or more objects seem related but it is very difficult to define common interface methods because of its underlying differences?
Lets say for example, an interface named IConnection with a Connect() method. (this is how most examples trivialize interfaces). The problem is, different type of classes that implement the IConnection interface might require different data for establishing the connection, some might require a user name and password, some might require some kind of special connection key, some might require nothing at all. The Connect method as a contract is perfectly valid as each class will need some way of establishing a connection but the data they need is different.
Is an interface required in this case? If it is, how do you define the Connect method? If not, how do you prove that your concrete classes are still 'extendable'?
Sorry for the long rant, this has been bugging me for quite some time now. Most people after reading the famous design patterns book try to implement every possible pattern in everything they do without bothering to figure out whether it helps. I believe the pattern should be brought into play when you are faced with a problem not just for the heck of it.
In your IConnection example you're basically describing an abstract Connect() method, since each class will have to implement its own version. Usually (always?) abstract methods can only be defined with the same parameters, so Connect(username, password) and Connect(key) couldn't be implementations of the same Connect() method from an interface.
Now, at this point, you could define it as IConnection::Connect(SomeConnectionData) and derive UsernamePasswordConnectionData and KeyConnectionData, etc., etc. from that SomeConnectionData class but all this would be so hard to explain and implement that its pretty good clue that interfaces and inheritance aren't helping the situation.
If it makes programming it and using it harder, don't do it. If something is made "extendable" by becoming too complex to understand, no will extend it anyway. It's perfectly okay to define a bunch of classes, each with their own Connect() methods just as a convention.
A dual interface in COM is one that is able to be accessed via a DispInterface or via VTable methods.
Now can someone tell me what is exactly what the difference is between the two methods?
I thought that a VTable is a virtual table which holds the pointers to the different functions when implementing a class hierarchy which has virtual functions that can be overridden in child classes. However I do not see how this is related to a dual interface in COM?
In short, COM is binary specification, not a language specification. There really isn't a correlation between dual interfaces and deriving classes in code. Apples and oranges.
The VTable is "early bound" and this therefore faster. You know the type of method you are calling at compile time.
Using the DispInterface is "late bound" and is therefore slower, but more flexible. It's used extensively for scripting. The method and property types are determined at runtime.
I hope this brief explanation helps.
The main difference is in the way of calling object methods. In the case of DispInterface call goes through IDispatch::Invoke method (used in scripts or in the absence of the interface description) see remarks. This method is much slower second option. In the second case used directly VTable for method calls (used for calls from C + + or. NET languages)
I want only answer to additional Tony's questions.
If you want create a COM which can be accessible from VBScript/JScript or from old "classic" ASP you have to implement IDispatch.
In Visual Basic 6 or in VBA of MS Office one can use both ways. If you add Reference to your COM, then you will be use "early bound" (IUnknown or VTable). If you use your COM in VB6 or VBA with CreateObject ("ProgIdName"), that you will be use "late bound".
It is very important to understand, that to make COM accessible from VB6/VBA ect. it's not enough just implement IUnknown interface. You have to create and register Type Library with oleautomation attribute. To be able to do so, you can use in the interface of your COM only oleautomation compatible data types (see http://msdn.microsoft.com/en-us/library/aa367129%28VS.85%29.aspx). For understanding the type library play a role of client marshaling DLL, so it helps a client software like VB6/VBA to send correctly data as a parameters to your COM. You should don't forget, that even your COM will be an InProc server, a DLL, parameters will be not forwards directly to COM, but need be marshaled. During marshaling a copy of data will be created on the thread where run your COM. It makes your COM DLL thread safe from one side and you COM will be not crash if the thread calling your COM method will be ended before COM returns the value.
Probably my explanation about marshaling is not easy, but it's just important don't forget to create and register the Type Library which is better to save as a resource inside of COM.