Tue, 03 Feb 2009 17:10:05 +0000
Jabber IQ handlers should handle non-query child nodes
Historically, all IQ stanzas had a query child; this is no longer the case
(XMPP Ping, Entity Time, etc). Instead, have the handlers use the first
child of the IQ stanza.
Also reduce some of the duplication in XMPP ping code (just use the one in
ping.c)
|
17805
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
1 | /* |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
2 | * purple - Jabber Protocol Plugin |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
3 | * |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
4 | * Copyright (C) 2007, Andreas Monitzer <andy@monitzer.com> |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
5 | * |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
6 | * This program is free software; you can redistribute it and/or modify |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
7 | * it under the terms of the GNU General Public License as published by |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
8 | * the Free Software Foundation; either version 2 of the License, or |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
9 | * (at your option) any later version. |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
10 | * |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
11 | * This program is distributed in the hope that it will be useful, |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
12 | * but WITHOUT ANY WARRANTY; without even the implied warranty of |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
13 | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
14 | * GNU General Public License for more details. |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
15 | * |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
16 | * You should have received a copy of the GNU General Public License |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
17 | * along with this program; if not, write to the Free Software |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
18 | * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
19 | * |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
20 | */ |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
21 | |
|
19898
218e4bb04853
Fix mingw build of xmpp prpl
Daniel Atallah <datallah@pidgin.im>
parents:
18797
diff
changeset
|
22 | #include "internal.h" |
|
218e4bb04853
Fix mingw build of xmpp prpl
Daniel Atallah <datallah@pidgin.im>
parents:
18797
diff
changeset
|
23 | |
|
17805
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
24 | #include "adhoccommands.h" |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
25 | #include <string.h> |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
26 | #include "internal.h" |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
27 | #include "xdata.h" |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
28 | #include "iq.h" |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
29 | #include "request.h" |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
30 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
31 | static void do_adhoc_ignoreme(JabberStream *js, ...) { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
32 | /* we don't have to do anything */ |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
33 | } |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
34 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
35 | typedef struct _JabberAdHocActionInfo { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
36 | char *sessionid; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
37 | char *who; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
38 | char *node; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
39 | GList *actionslist; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
40 | } JabberAdHocActionInfo; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
41 | |
|
17816
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
42 | void jabber_adhoc_disco_result_cb(JabberStream *js, xmlnode *packet, gpointer data) { |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
43 | const char *from = xmlnode_get_attrib(packet, "from"); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
44 | const char *type = xmlnode_get_attrib(packet, "type"); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
45 | const char *node; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
46 | xmlnode *query, *item; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
47 | JabberID *jabberid; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
48 | JabberBuddy *jb; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
49 | JabberBuddyResource *jbr = NULL; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
50 | |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
51 | if(strcmp(type, "result")) |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
52 | return; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
53 | |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
54 | query = xmlnode_get_child_with_namespace(packet,"query","http://jabber.org/protocol/disco#items"); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
55 | if(!query) |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
56 | return; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
57 | node = xmlnode_get_attrib(query,"node"); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
58 | if(!node || strcmp(node, "http://jabber.org/protocol/commands")) |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
59 | return; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
60 | |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
61 | if((jabberid = jabber_id_new(from))) { |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
62 | if(jabberid->resource && (jb = jabber_buddy_find(js, from, TRUE))) |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
63 | jbr = jabber_buddy_find_resource(jb, jabberid->resource); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
64 | jabber_id_free(jabberid); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
65 | } |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
66 | |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
67 | if(!jbr) |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
68 | return; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
69 | |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
70 | if(jbr->commands) { |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
71 | /* since the list we just received is complete, wipe the old one */ |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
72 | while(jbr->commands) { |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
73 | JabberAdHocCommands *cmd = jbr->commands->data; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
74 | g_free(cmd->jid); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
75 | g_free(cmd->node); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
76 | g_free(cmd->name); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
77 | g_free(cmd); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
78 | jbr->commands = g_list_delete_link(jbr->commands, jbr->commands); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
79 | } |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
80 | } |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
81 | |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
82 | for(item = query->child; item; item = item->next) { |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
83 | JabberAdHocCommands *cmd; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
84 | if(item->type != XMLNODE_TYPE_TAG) |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
85 | continue; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
86 | if(strcmp(item->name, "item")) |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
87 | continue; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
88 | cmd = g_new0(JabberAdHocCommands, 1); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
89 | |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
90 | cmd->jid = g_strdup(xmlnode_get_attrib(item,"jid")); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
91 | cmd->node = g_strdup(xmlnode_get_attrib(item,"node")); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
92 | cmd->name = g_strdup(xmlnode_get_attrib(item,"name")); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
93 | |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
94 | jbr->commands = g_list_append(jbr->commands,cmd); |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
95 | } |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
96 | } |
|
17805
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
97 | |
|
17838
c6427caf2cfe
Fixed a bug that prevented multi-stage ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
17818
diff
changeset
|
98 | static void jabber_adhoc_parse(JabberStream *js, xmlnode *packet, gpointer data); |
|
c6427caf2cfe
Fixed a bug that prevented multi-stage ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
17818
diff
changeset
|
99 | |
|
17805
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
100 | static void do_adhoc_action_cb(JabberStream *js, xmlnode *result, const char *actionhandle, gpointer user_data) { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
101 | xmlnode *command; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
102 | GList *action; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
103 | JabberAdHocActionInfo *actionInfo = user_data; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
104 | JabberIq *iq = jabber_iq_new(js, JABBER_IQ_SET); |
|
17838
c6427caf2cfe
Fixed a bug that prevented multi-stage ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
17818
diff
changeset
|
105 | jabber_iq_set_callback(iq, jabber_adhoc_parse, NULL); |
|
17805
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
106 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
107 | xmlnode_set_attrib(iq->node, "to", actionInfo->who); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
108 | command = xmlnode_new_child(iq->node,"command"); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
109 | xmlnode_set_namespace(command,"http://jabber.org/protocol/commands"); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
110 | xmlnode_set_attrib(command,"sessionid",actionInfo->sessionid); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
111 | xmlnode_set_attrib(command,"node",actionInfo->node); |
|
20294
5af4a755ab36
applied changes from b8fa91b64c41d38520d7944d70d627007e271158
John Bailey <rekkanoryo@rekkanoryo.org>
parents:
20169
diff
changeset
|
112 | |
|
5af4a755ab36
applied changes from b8fa91b64c41d38520d7944d70d627007e271158
John Bailey <rekkanoryo@rekkanoryo.org>
parents:
20169
diff
changeset
|
113 | /* cancel is handled differently on ad-hoc commands than regular forms */ |
|
5af4a755ab36
applied changes from b8fa91b64c41d38520d7944d70d627007e271158
John Bailey <rekkanoryo@rekkanoryo.org>
parents:
20169
diff
changeset
|
114 | if(!strcmp(xmlnode_get_namespace(result),"jabber:x:data") && !strcmp(xmlnode_get_attrib(result, "type"),"cancel")) { |
|
5af4a755ab36
applied changes from b8fa91b64c41d38520d7944d70d627007e271158
John Bailey <rekkanoryo@rekkanoryo.org>
parents:
20169
diff
changeset
|
115 | xmlnode_set_attrib(command,"action","cancel"); |
|
5af4a755ab36
applied changes from b8fa91b64c41d38520d7944d70d627007e271158
John Bailey <rekkanoryo@rekkanoryo.org>
parents:
20169
diff
changeset
|
116 | } else { |
|
5af4a755ab36
applied changes from b8fa91b64c41d38520d7944d70d627007e271158
John Bailey <rekkanoryo@rekkanoryo.org>
parents:
20169
diff
changeset
|
117 | if(actionhandle) |
|
5af4a755ab36
applied changes from b8fa91b64c41d38520d7944d70d627007e271158
John Bailey <rekkanoryo@rekkanoryo.org>
parents:
20169
diff
changeset
|
118 | xmlnode_set_attrib(command,"action",actionhandle); |
|
5af4a755ab36
applied changes from b8fa91b64c41d38520d7944d70d627007e271158
John Bailey <rekkanoryo@rekkanoryo.org>
parents:
20169
diff
changeset
|
119 | xmlnode_insert_child(command,result); |
|
5af4a755ab36
applied changes from b8fa91b64c41d38520d7944d70d627007e271158
John Bailey <rekkanoryo@rekkanoryo.org>
parents:
20169
diff
changeset
|
120 | } |
|
17805
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
121 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
122 | for(action = actionInfo->actionslist; action; action = g_list_next(action)) { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
123 | char *handle = action->data; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
124 | g_free(handle); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
125 | } |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
126 | g_list_free(actionInfo->actionslist); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
127 | g_free(actionInfo->sessionid); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
128 | g_free(actionInfo->who); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
129 | g_free(actionInfo->node); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
130 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
131 | jabber_iq_send(iq); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
132 | } |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
133 | |
|
17818
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
134 | static void jabber_adhoc_parse(JabberStream *js, xmlnode *packet, gpointer data) { |
|
17805
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
135 | xmlnode *command = xmlnode_get_child_with_namespace(packet, "command", "http://jabber.org/protocol/commands"); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
136 | const char *status = xmlnode_get_attrib(command,"status"); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
137 | xmlnode *xdata = xmlnode_get_child_with_namespace(command,"x","jabber:x:data"); |
|
18797
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
138 | const char *type = xmlnode_get_attrib(packet,"type"); |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
139 | |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
140 | if(type && !strcmp(type,"error")) { |
|
21150
bedd1215fb5e
Stop jabber setting wants_to_die itself. This involved plumbing disconnection
Will Thompson <resiak@pidgin.im>
parents:
20169
diff
changeset
|
141 | char *msg = jabber_parse_error(js, packet, NULL); |
|
18797
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
142 | if(!msg) |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
143 | msg = g_strdup(_("Unknown Error")); |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
144 | |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
145 | purple_notify_error(NULL, _("Ad-Hoc Command Failed"), |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
146 | _("Ad-Hoc Command Failed"), msg); |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
147 | g_free(msg); |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
148 | return; |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
149 | } |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
150 | if(!type || strcmp(type,"result")) |
|
0cff7a4d0449
Implemented error handling for ad-hoc commands.
Andreas Monitzer <am@adiumx.com>
parents:
18754
diff
changeset
|
151 | return; |
|
17805
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
152 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
153 | if(!status) |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
154 | return; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
155 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
156 | if(!strcmp(status,"completed")) { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
157 | /* display result */ |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
158 | xmlnode *note = xmlnode_get_child(command,"note"); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
159 | |
|
20169
497e1cd1e059
Merged xmpp leak fixes
Evan Schoenberg <evands@pidgin.im>
parents:
19994
diff
changeset
|
160 | if(note) { |
|
497e1cd1e059
Merged xmpp leak fixes
Evan Schoenberg <evands@pidgin.im>
parents:
19994
diff
changeset
|
161 | char *data = xmlnode_get_data(note); |
|
497e1cd1e059
Merged xmpp leak fixes
Evan Schoenberg <evands@pidgin.im>
parents:
19994
diff
changeset
|
162 | purple_notify_info(NULL, xmlnode_get_attrib(packet, "from"), data, NULL); |
|
497e1cd1e059
Merged xmpp leak fixes
Evan Schoenberg <evands@pidgin.im>
parents:
19994
diff
changeset
|
163 | g_free(data); |
|
497e1cd1e059
Merged xmpp leak fixes
Evan Schoenberg <evands@pidgin.im>
parents:
19994
diff
changeset
|
164 | } |
|
17805
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
165 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
166 | if(xdata) |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
167 | jabber_x_data_request(js, xdata, (jabber_x_data_cb)do_adhoc_ignoreme, NULL); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
168 | return; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
169 | } |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
170 | if(!strcmp(status,"executing")) { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
171 | /* this command needs more steps */ |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
172 | xmlnode *actions, *action; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
173 | int actionindex = 0; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
174 | GList *actionslist = NULL; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
175 | JabberAdHocActionInfo *actionInfo; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
176 | if(!xdata) |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
177 | return; /* shouldn't happen */ |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
178 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
179 | actions = xmlnode_get_child(command,"actions"); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
180 | if(!actions) { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
181 | JabberXDataAction *defaultaction = g_new0(JabberXDataAction, 1); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
182 | defaultaction->name = g_strdup(_("execute")); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
183 | defaultaction->handle = g_strdup("execute"); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
184 | actionslist = g_list_append(actionslist, defaultaction); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
185 | } else { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
186 | const char *defaultactionhandle = xmlnode_get_attrib(actions, "execute"); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
187 | int index = 0; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
188 | for(action = actions->child; action; action = action->next, ++index) { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
189 | if(action->type == XMLNODE_TYPE_TAG) { |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
190 | JabberXDataAction *newaction = g_new0(JabberXDataAction, 1); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
191 | newaction->name = g_strdup(_(action->name)); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
192 | newaction->handle = g_strdup(action->name); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
193 | actionslist = g_list_append(actionslist, newaction); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
194 | if(defaultactionhandle && !strcmp(defaultactionhandle, action->name)) |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
195 | actionindex = index; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
196 | } |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
197 | } |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
198 | } |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
199 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
200 | actionInfo = g_new0(JabberAdHocActionInfo, 1); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
201 | actionInfo->sessionid = g_strdup(xmlnode_get_attrib(command,"sessionid")); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
202 | actionInfo->who = g_strdup(xmlnode_get_attrib(packet,"from")); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
203 | actionInfo->node = g_strdup(xmlnode_get_attrib(command,"node")); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
204 | actionInfo->actionslist = actionslist; |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
205 | |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
206 | jabber_x_data_request_with_actions(js,xdata,actionslist,actionindex,do_adhoc_action_cb,actionInfo); |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
207 | } |
|
5bd417a1c847
Implemented XEP-0050: Ad-Hoc Commands. Note that this XEP requires sending an initial command to the peer, which is not implemented in libpurple itself (since this requires a discovery browser or equivalent).
Andreas Monitzer <am@adiumx.com>
parents:
diff
changeset
|
208 | } |
|
17816
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
209 | |
|
17818
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
210 | void jabber_adhoc_execute_action(PurpleBlistNode *node, gpointer data) { |
|
17816
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
211 | if (PURPLE_BLIST_NODE_IS_BUDDY(node)) { |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
212 | JabberAdHocCommands *cmd = data; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
213 | PurpleBuddy *buddy = (PurpleBuddy *) node; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
214 | JabberStream *js = purple_account_get_connection(buddy->account)->proto_data; |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
215 | |
|
17818
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
216 | jabber_adhoc_execute(js, cmd); |
|
17816
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
217 | } |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
218 | } |
|
1b7362b4a7a2
Implemented ad-hoc commands for the buddy action menu (untested), implemented the receiving end of XEP-0115: Entity Capabilities. Note that this seems not to be reliable right now, since some clients seem to have a very broken [read: completely non-functional] implementation (most notably Gajim and the py-transports).
Andreas Monitzer <am@adiumx.com>
parents:
17806
diff
changeset
|
219 | |
|
17817
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
220 | static void jabber_adhoc_server_got_list_cb(JabberStream *js, xmlnode *packet, gpointer data) { |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
221 | xmlnode *query = xmlnode_get_child_with_namespace(packet, "query", "http://jabber.org/protocol/disco#items"); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
222 | xmlnode *item; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
223 | |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
224 | if(!query) |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
225 | return; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
226 | |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
227 | /* clean current list (just in case there is one) */ |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
228 | while(js->commands) { |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
229 | JabberAdHocCommands *cmd = js->commands->data; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
230 | g_free(cmd->jid); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
231 | g_free(cmd->node); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
232 | g_free(cmd->node); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
233 | g_free(cmd); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
234 | js->commands = g_list_delete_link(js->commands, js->commands); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
235 | } |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
236 | |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
237 | /* re-fill list */ |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
238 | for(item = query->child; item; item = item->next) { |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
239 | JabberAdHocCommands *cmd; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
240 | if(item->type != XMLNODE_TYPE_TAG) |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
241 | continue; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
242 | if(strcmp(item->name, "item")) |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
243 | continue; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
244 | cmd = g_new0(JabberAdHocCommands, 1); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
245 | cmd->jid = g_strdup(xmlnode_get_attrib(item,"jid")); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
246 | cmd->node = g_strdup(xmlnode_get_attrib(item,"node")); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
247 | cmd->name = g_strdup(xmlnode_get_attrib(item,"name")); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
248 | |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
249 | js->commands = g_list_append(js->commands,cmd); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
250 | } |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
251 | } |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
252 | |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
253 | void jabber_adhoc_server_get_list(JabberStream *js) { |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
254 | JabberIq *iq = jabber_iq_new_query(js,JABBER_IQ_GET,"http://jabber.org/protocol/disco#items"); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
255 | xmlnode *query = xmlnode_get_child_with_namespace(iq->node,"query","http://jabber.org/protocol/disco#items"); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
256 | |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
257 | xmlnode_set_attrib(iq->node,"to",js->user->domain); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
258 | xmlnode_set_attrib(query,"node","http://jabber.org/protocol/commands"); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
259 | |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
260 | jabber_iq_set_callback(iq,jabber_adhoc_server_got_list_cb,NULL); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
261 | jabber_iq_send(iq); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
262 | } |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
263 | |
|
17818
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
264 | void jabber_adhoc_execute(JabberStream *js, JabberAdHocCommands *cmd) { |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
265 | JabberIq *iq = jabber_iq_new(js, JABBER_IQ_SET); |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
266 | xmlnode *command = xmlnode_new_child(iq->node,"command"); |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
267 | xmlnode_set_attrib(iq->node,"to",cmd->jid); |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
268 | xmlnode_set_namespace(command,"http://jabber.org/protocol/commands"); |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
269 | xmlnode_set_attrib(command,"node",cmd->node); |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
270 | xmlnode_set_attrib(command,"action","execute"); |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
271 | |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
272 | jabber_iq_set_callback(iq,jabber_adhoc_parse,NULL); |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
273 | |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
274 | jabber_iq_send(iq); |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
275 | } |
|
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
276 | |
|
19899
483c4f495a6c
Various warning fixes for the xmpp prpl.
Daniel Atallah <datallah@pidgin.im>
parents:
19898
diff
changeset
|
277 | static void jabber_adhoc_server_execute(PurplePluginAction *action) { |
|
17817
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
278 | JabberAdHocCommands *cmd = action->user_data; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
279 | if(cmd) { |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
280 | PurpleConnection *gc = (PurpleConnection *) action->context; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
281 | JabberStream *js = gc->proto_data; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
282 | |
|
17818
ebd51078c0e6
Now all ad-hoc commands have to be sent through jabber_adhoc_execute to be properly executed (including the form steps). This cleans up the code a bit, and avoids DOS attacks by flooding the client with malicious ad-hoc command forms that were not requested.
Andreas Monitzer <am@adiumx.com>
parents:
17817
diff
changeset
|
283 | jabber_adhoc_execute(js, cmd); |
|
17817
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
284 | } |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
285 | } |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
286 | |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
287 | void jabber_adhoc_init_server_commands(JabberStream *js, GList **m) { |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
288 | GList *cmdlst; |
|
18725
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
289 | JabberBuddy *jb; |
|
17817
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
290 | |
|
18725
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
291 | /* also add commands for other clients connected to the same account on another resource */ |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
292 | char *accountname = g_strdup_printf("%s@%s", js->user->node, js->user->domain); |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
293 | if((jb = jabber_buddy_find(js, accountname, TRUE))) { |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
294 | GList *iter; |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
295 | for(iter = jb->resources; iter; iter = g_list_next(iter)) { |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
296 | JabberBuddyResource *jbr = iter->data; |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
297 | GList *riter; |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
298 | for(riter = jbr->commands; riter; riter = g_list_next(riter)) { |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
299 | JabberAdHocCommands *cmd = riter->data; |
|
18754
d0a3169c8f29
Switched formatting of the ad-hoc commands to be less intimidating
Andreas Monitzer <am@adiumx.com>
parents:
18725
diff
changeset
|
300 | char *cmdname = g_strdup_printf("%s (%s)",cmd->name,jbr->name); |
|
18725
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
301 | PurplePluginAction *act = purple_plugin_action_new(cmdname, jabber_adhoc_server_execute); |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
302 | act->user_data = cmd; |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
303 | *m = g_list_append(*m, act); |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
304 | g_free(cmdname); |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
305 | } |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
306 | } |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
307 | } |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
308 | g_free(accountname); |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
309 | |
|
a3ab5c711de7
Now showing ad-hoc commands of other clients connected to the same account in the account menu (per XEP-0146). Since it is becoming messy in that menu, I also prefixed all ad-hoc commands with the node this command belongs to in [], which is the resource name for clients and the domain name for the server. Examples: "[home] Set status" for clients and "[jabber.org] Send message to all connected users" for servers.
Andreas Monitzer <am@adiumx.com>
parents:
17838
diff
changeset
|
310 | /* now add server commands */ |
|
17817
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
311 | for(cmdlst = js->commands; cmdlst; cmdlst = g_list_next(cmdlst)) { |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
312 | JabberAdHocCommands *cmd = cmdlst->data; |
|
18754
d0a3169c8f29
Switched formatting of the ad-hoc commands to be less intimidating
Andreas Monitzer <am@adiumx.com>
parents:
18725
diff
changeset
|
313 | PurplePluginAction *act = purple_plugin_action_new(cmd->name, jabber_adhoc_server_execute); |
|
17817
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
314 | act->user_data = cmd; |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
315 | *m = g_list_append(*m, act); |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
316 | } |
|
8e0f271aab78
The server's ad-hoc commands are now listed in the account's action menu. Note that this requires an additional field in the _PurplePluginAction struct. There's no other way, since there was no way to supply user_data, and dynamically created functions are not supported by C. This should be fine, since that struct is only malloced in purple_plugin_action_new, which is part of the core. Applications have to either pass the struct unmodified, or restore the user_data pointer if the action is recreated when necessary (as is the case in Adium).
Andreas Monitzer <am@adiumx.com>
parents:
17816
diff
changeset
|
317 | } |