1

Topic: Double-sided interfaces

Let's admit, there are two program units wishing  with each other. For the interaction organization the method at which these two units agree about certain API (or one side dictates and the second agrees or as that is still formed this general API - basically not important) is standard, then each of the sides implements the part, well and then they simply start to work according to the arrangement. There is a mass  methods/tools for the organization of provision API, for the most different environments. Here some  -  interfaces, in the form of the feature set, described in the language, exported from so/dll/exe - CORBA/COM/XPCOM-like interfaces - HTTP/SMTP/FTP similar protocols - application-oriented over REST/SOAP similar-... API are normally made out in the form of 1. Feature set, probably, grouped in certain semanticheski-complete bunches round such ' entities ' 2. Auxiliary data structures, ,  and other ' links to remote states/objects ' 3. The constants-tokens marking what or attributes/signs/actions 4.... Example API for operation with files: https://www.opennet.ru/man.shtml?topic=fopen https://www.opennet.ru/man.shtml?topic=fseek https://www.opennet.ru/man.shtml?topic=fread https://www.opennet.ru/man.shtml?topic=fclose Example API for operation with posts in a blog: https://developer.wordpress.org/rest-ap … nce/posts/ Normally those interfaces offer the pure client server approach at which the user-client initiates activity by means of influence on the interface, on the other hand the interface the certain service reacting to activity of the user is allocated. In the pure state service cannot initiate activity. That service all the same could initiate activity - apply inverse of the same client server approach more often, in particular, the user gives to service the interface-kalbek concerning which - service itself becomes the user, and the user - service. An example: http://docs.libuv.org/en/v1.x/udp.html#c.uv_udp_send (the friend udp-handle, departed bufs on addr as you will finish - notify me a call of mine send_cb, and I while will be engaged in other questions) Still an example: https://msdn.microsoft.com/en-us/librar … p/aa365261 (v=vs.85).aspx (the friend , see  for such that a folder about modifications if that that happens - cock event dwChangeHandles [0], I will catch it upon for now I will be engaged than  still) Is also other methods to force service to initiate activity, for example, long polling, the active inquiry..., but it is already such artful hacker '  ', not interesting. An example long polling: https://doc.qt.io/qt-5/qiodevice.html#waitForReadyRead (friend Qt, freeze  me while there is nothing to read, but no more than on msecs. All the same dataless it nothing me. And if that does - I in other flow it will do) Still an example: comet Mine : to provide equality  the sides concerning activity initiation My problem: There is no mainstream of techniques of support of such equality, and that that is - or difficult constructions which should be raised and supported hands, or too sophisticated khaki. The possible decision - to refuse from API on functions in favor of API, messages based on asynchronous sendings (message based). Such method is quite used in practice, but shows some specificity to the communicating sides. Application-oriented variants of usage in which it would be more convenient to use the coherent pair ' request-answer ' instead of one ' messages ' - in my opinion all the same more. It would not be desirable to refuse functions. Still the possible decision -  a source of activity at the expense of "signals". https://doc.qt.io/qt-5/signalsandslots.html http://www.boost.org/doc/libs/1_66_0/do … nals2.html Thus, in the interface, along with methods - there are new passengers of the first class - signals. In Qt it practises almost everywhere, very conveniently and quite expressively. Such decision does not contradict a principle a client - server (request-answer), but adds it, allowing to initiate requests to any side, and not just one. At such decision message based the approach all the same can take place, and quite legally. For example, function invocation which returns nothing is an equivalent ' message sendings '. An example of the double-sided interface (such input-output a device from Qt): https://doc.qt.io/qt-5/qiodevice.html in particular, a counter part here https://doc.qt.io/qt-5/qiodevice.html#signals the Example of the double-sided interface (a such UDP-socket): https://github.com/vopl/dci/blob/7bd4f2 … t.idl#L115 implementation https://github.com/vopl/dci/blob/7bd4f2 … el.hpp#L27 https://github.com/vopl/dci/blob/7bd4f2 … el.cpp#L27 usage https://github.com/vopl/dci/blob/7bd4f2 … mm.cpp#L32 On this site as that time rose a similar subject, but there there were still some other conceptual , darkened a subject here start of a comprehensive subject http://rsdn.org/forum/philosophy/4953388 the Author: AndrewVK Date: 05.11.12 pictures from the author of that subject http://4.bp.blogspot.com/-9gRPwt92DRA/U … 600/03.png http://4.bp.blogspot.com/-MY-5wxNXE_0/U … 600/04.png http://4.bp.blogspot.com/-ml8W9AfQbts/U … 600/05.png http://4.bp.blogspot.com/-VH1DY2-ZIAo/U … 600/06.png from here and deep into can be esteemed http://rsdn.org/forum/philosophy/4950901.1 the Author: vdimas Date: 02.11.12 http://rsdn.org/forum/philosophy/4952006.1 the Author: VladD2 Date: 03.11.12 http://rsdn.org/forum/philosophy/4952394.1 the Author: AlexCab Date: 04.11.12 Small comparing with classical ' request-answer ' interfaces. - server push from a box. Actually, ' the server ' ceases to be that,  in ' one of the sides p2p '. Under the server and p2p I mean not specific network technologies, and the basic sense. The example above about a subscription on  about changes in file system, could look approximately so interface FsChangesObserver {in startWatch (string path); in stopWatch (string path); out created (string path); out moved (string src, string dst); out deleted (string path);//...} - some  differences between ' the user ' and ' service '. The previous interface, from the executor  - will look mirroring: interface FsChangesObserver <back> {out startWatch (string path); out stopWatch (string path); in created (string path); in moved (string src, string dst); in deleted (string path);//...} The method of implementation of the executor  concerning the given interface will be in accuracy same, as at a customer  on the other hand. To within mirror display. To subscribe for out-signals and in time to pull in-SLOTS. - the topology of connection of the communicating sides among themselves a little changes. Between the communicating sides there is quite to itself an independent piece - the interface. The interface copy ceases to have a rigid binding to implementation, it becomes as though in itself, and round it two its users. - owing to independence of a copy of the interface -  the communicating sides (moreover and built in a chain for example) there is more simple. Though, here it is possible to argue, situations different happen. - the interface copy has now a state and should itself  its storage and support (in particular to conduct registers of the connected slots to signals to keep account the users from both sides...) -  ' the user-service ' does not disappear anywhere, it all as takes place, but only now it not one on all interface as a whole, and now it is a lot of them, to each signal/SLOT separately. If it is a signal - means it is necessary to listen and answer, if it is the slot - that can be made on it request and to receive the answer.------------------ can eat what that serious contra-indications for such double-sided interfaces? While I see only such reasons: 1. So it was historically added, an eye already  by classics, and like as though and it is necessary 2. It is more difficult than classical API on methods and to whom strongly it is necessary - let does the bicycles

2

Re: Double-sided interfaces

Made inquiry here the Author: vopl Date: 11.03 15:19 Question: Being what developer or the program components, what types API should be used for the organization of interaction with other program pieces

3

Re: Double-sided interfaces

4

Re: Double-sided interfaces

Hello, netch80, you wrote: V>> Mine : to provide equality  the sides concerning initiation of activity V>> My problem: there is no mainstream of techniques of support of such equality, and that that is - or difficult constructions which should be raised and supported hands, or too sophisticated khaki. N> it was straight off recalled Session Initiation Protocol (this). There fair equality at all levels. V>> the possible decision - to refuse from API on functions in favor of API, messages based on asynchronous sendings (message based). Such method is quite used in practice, but shows some specificity to the communicating sides. N> it is specificity of the task, instead of a specific method. If you generally bring an attention to the question of equality of the sides it is necessary to be ready that other side sends something unexpectedly and it is necessary to react to it - including when the side sent request and the answer to him expects. And, means, asynchronous implementation - unique in this case. N> in the same SIP it pretty often. You re-INVITE, you towards re-INVITE. Most simple and even recommended - to refuse "the conflict of updates" and to make resending through casual time. Well, here I too so think, only I look at it from some other side. My theses: - asynchrony is when any of two sides can initiate activity at any moment - the elementary method to involve asynchrony - to use double-sided message-based a method. Message-based I here resulted as ' one of classical methods '. You it is correct  ' asynchrony '. Further I stretch ' asynchrony ' on ' function-based ' as very much the sheaf attracts request-answer - asynchrony can be implemented and on requests-answers (function-based), as for example in Qt: On the one hand, the user of the button (the application-oriented code) during the arbitrary moment of time can tell to it that  and receive the answer: QPoint request =...; QPoint response = pButton-> mapFromParent (request);//process response//... On the other hand, the button itself can initiate activity in relation to the user: onToggled = function (bool request)-> Response {//process request//... return Response ();}; pButton.connect (... &toggled..., &onToggled); That is, both sides can initiate activity. In it also there is an equality.... N> for interfaces - I think, here the general method is not present, but it and is not strongly possible at an essential variety of implementations and requirements - from which general only "as something new comes, call me by this phone". It is a little not so. Double-sided asynchronous messages: "as something new comes, double-sided asynchronous requests-answers came to me  by this phone":" As something new comes, call me by this phone and tell, I will answer you in the same call "the Possible general method for interfaces - to use not only functions, but also the turned functions, they ' signals '.

5

Re: Double-sided interfaces

Hello, vopl, you wrote: V> the Possible general method for interfaces - to use not only functions, but also the turned functions, they ' signals '. And how it is supposed  a correctness of protocols on the basis of the general method?

6

Re: Double-sided interfaces

Hello, Sharov, you wrote: V>> the Possible general method for interfaces - to use not only functions, but also the turned functions, they ' signals '. S> And how it is supposed  a correctness of protocols on the basis of the general method? The same as  a correctness in message-based, function-based: 1. At the expense of typification which does not allow to make the arbitrary request or the answer if the type of this request or the answer is set. For example: interface Danila {in whatIsThePowerBrother ()-> Truth; out iNeedHelp (Address iAmHere)-> SomeHelp;} ... Danila iam =...; iam.whatIsThePowerBrother = function ()-> Truth {return 200$;//it will not be compiled, in money there is no force} 2. At the expense of application-oriented logic over the received value of request/answer Danila:: Opposite den =...;//from Dehn den.iNeedHelp = function (Address danilaLocation)-> SomeHelp {if ("America"! = danilaLocation) {throw DontPlayPrankster ();//response on  request} return SomeHelp (money, planeTickets);}...//from Daniel SomeHelp help = den.iNeedHelp ("America"); if (! help.contains (' guns')) {den = null;//response on  the answer}