There’‘s a lot more downsides than just that. At some point when I have time I’‘ll write out a document about what problems are dodged by using internals and try to see if I can’'t push for things to be ‘‘fixed’’ on a more global basis, so all transports can benefit from it, not just this plugin.
If the person’'s server who connected to had something other than the IM gateway plugin, then yes you would have gotten bombarded.
PyAIMt, PyICQt, PyMSNt, all require you to accept all of your contacts into your real XMPP roster unfortunately. That can lead to a lot of problems. There’‘s a lot of problems associated with the transport not knowing anything specific about your roster. Like there’‘s no way for it to know if you’‘ve deleted contacts since you last used it. It may be merrily going along thinking you have email@example.com on your list and you really don’'t.
The plugin does -not- have this problem because it just up and puts people into your roster behind the scenes. It can also compare with your current roster and make sure things are properly synced up. Furthermore, it doesn’‘t put the contacts in your actual roster, so if you unsubscribe from your, for example, AIM transport, you won’'t end up with a bazillion leftover aim.yourserver.org contacts in your roster that are useless.
The bombardment of adds and such has been known to cause a lot of problems for end users in general though. Sure if you only have 5 or 6 it’‘s probably nothing. But some folk using PyICQt, for example, have many hundreds. I’‘m surprised some of these folk haven’‘t hit max list caps on the OSCAR servers. Anyway, the bombardment can cause a lot of shock value for the end user, lead them to sit there clicking over and over again … sometimes it even fires up enough requests to create the user’'s client. Often it brings their machine to a crawl briefly.
Anyway, like I said, there’‘s no “soon” plans of implementing anything for remote users. You might want to look into the alternative offerings if that’'s what you are after. =)