Mercurial > libervia-backend

diff src/plugins/plugin_misc_text_commands.py @ 2144:1d3f73e065e1

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
core, jp: component handling + client handling refactoring: - SàT can now handle components - plugin have now a "modes" key in PLUGIN_INFO where they declare if they can be used with clients and or components. They default to be client only. - components are really similar to clients, but with some changes in behaviour: * component has "entry point", which is a special plugin with a componentStart method, which is called just after component is connected * trigger end with a different suffixes (e.g. profileConnected vs profileConnectedComponent), so a plugin which manage both clients and components can have different workflow * for clients, only triggers of plugins handling client mode are launched * for components, only triggers of plugins needed in dependencies are launched. They all must handle component mode. * component have a sendHistory attribute (False by default) which can be set to True to allow saving sent messages into history * for convenience, "client" is still used in method even if it can now be a component * a new "component" boolean attribute tells if we have a component or a client * components have to add themselve Message protocol * roster and presence protocols are not added for components * component default port is 5347 (which is Prosody's default port) - asyncCreateProfile has been renamed for profileCreate, both to follow new naming convention and to prepare the transition to fully asynchronous bridge - createProfile has a new "component" attribute. When used to create a component, it must be set to a component entry point - jp: added --component argument to profile/create - disconnect bridge method is now asynchronous, this way frontends can know when disconnection is finished - new PI_* constants for PLUGIN_INFO values (not used everywhere yet) - client/component connection workflow has been moved to their classes instead of being a host methods - host.messageSend is now client.sendMessage, and former client.sendMessage is now client.sendMessageData. - identities are now handled in client.identities list, so it can be updated dynamically by plugins (in the future, frontends should be able to update them too through bridge) - profileConnecting* profileConnected* profileDisconnected* and getHandler now all use client instead of profile
author Goffi <goffi@goffi.org>
date Sun, 12 Feb 2017 17:55:43 +0100
parents aa94f33fd2ad
children 33c8c4973743
line wrap: on
line diff
--- a/src/plugins/plugin_misc_text_commands.py	Tue Feb 07 00:15:03 2017 +0100
+++ b/src/plugins/plugin_misc_text_commands.py	Sun Feb 12 17:55:43 2017 +0100
@@ -60,7 +60,7 @@
         log.info(_("Text commands initialization"))
         self.host = host
         # this is internal command, so we set high priority
-        host.trigger.add("messageSend", self.messageSendTrigger, priority=1000000)
+        host.trigger.add("sendMessage", self.sendMessageTrigger, priority=1000000)
         self._commands = {}
         self._whois = []
         self.registerTextCommands(self)
@@ -168,12 +168,12 @@
         self._whois.append((priority, callback))
         self._whois.sort(key=lambda item: item[0], reverse=True)
 
-    def messageSendTrigger(self, client, mess_data, pre_xml_treatments, post_xml_treatments):
+    def sendMessageTrigger(self, client, mess_data, pre_xml_treatments, post_xml_treatments):
         """Install SendMessage command hook """
-        pre_xml_treatments.addCallback(self._messageSendCmdHook, client)
+        pre_xml_treatments.addCallback(self._sendMessageCmdHook, client)
         return True
 
-    def _messageSendCmdHook(self, mess_data, client):
+    def _sendMessageCmdHook(self, mess_data, client):
         """ Check text commands in message, and react consequently
 
         msg starting with / are potential command. If a command is found, it is executed, else and help message is sent
@@ -181,7 +181,7 @@
         commands can abord message sending (if they return anything evaluating to False), or continue it (if they return True), eventually after modifying the message
         an "unparsed" key is added to message, containing part of the message not yet parsed
         commands can be deferred or not
-        @param mess_data(dict): data comming from messageSend trigger
+        @param mess_data(dict): data comming from sendMessage trigger
         @param profile: %(doc_profile)s
         """
         try:
@@ -254,7 +254,7 @@
     def _contextValid(self, mess_data, cmd_data):
         """Tell if a command can be used in the given context
 
-        @param mess_data(dict): message data as given in messageSend trigger
+        @param mess_data(dict): message data as given in sendMessage trigger
         @param cmd_data(dict): command data as returned by self._parseDocString
         @return (bool): True if command can be used in this context
         """
@@ -290,7 +290,7 @@
         mess_data["type"] = C.MESS_TYPE_INFO
         mess_data["message"] = {'': message}
         mess_data["extra"]["info_type"] = info_type
-        self.host.messageSendToBridge(mess_data, client)
+        self.host.sendMessageToBridge(mess_data, client)
 
     def cmd_whois(self, client, mess_data):
         """show informations on entity