cash wrote on 41220093-06-21

We need a little more information:

• By stream additions, do you mean posts to Elgg's wire?
• Did you configure the twitter api plugin?
• Did your test user configure his settings for Twitter?

cash wrote on 41347143-04-29

In 1.7 the wire plugin needs to trigger the twitter services plugin. This feels odd. I'd prefer the twitter services plugin to register for the create event on a wire post. Why should thewire know that the twitter services plugin exists?

Milestone changed to Elgg 1.8 by cash on 41347143-04-29

Title changed from Stream Additions do not post to twitter to Wire posts do not post to twitter by cash on 41347143-04-29

ewinslow wrote on 41348587-03-10

Agreed on those points, definitely.

brettp wrote on 41349796-06-29

I prefer the wire to trigger the twitter services plugin. This allows the twitter service to be loosely coupled with other plugins because someone could easily write a plugin that pushes content out to Twitter by calling the service plugin. If we put the hooks for create events in the service plugin we're either creating a finite list of plugins that can use it, or we're introducing multiple ways to interact with the Twitter API.

cash wrote on 41382750-04-24

1. The twitter api needs an option for turning posting to twitter for wire posts on/off (that or put it into the wire plugin - either requires an is_plugin_enabled() call)
2. I really prefer the twitter api plugin to listen for the creation of wire objects. There is no reason for the wire plugin to know about the twitter service api plugin.
3. It is still reasonable for the twitter api to provide a handler for a hook. I don't think we need to pick between the two.

Also, to generalize people may want to the wire posts to go other places (like Facebook). Having a trigger hardcoded for twitter seems out of place.

cash wrote on 41444534-10-18

Any responses to this one? This isn't hard to fix but we need to pick how we want to do this.

ewinslow wrote on 41449664-11-19

I'm with Cash on this one. Better for the content plugins to be agnostic about external services. It also just makes sense to me for the twitter plugin to listen for status updates within Elgg and push those by default. If we provide a hook for other content plugins to use, that's fine too.

brettp wrote on 41450148-03-14

I still prefer the other approach. The same arguments apply: There's no reason for the Twitter API plugin to know about The Wire and API plugins should be agnostic about content plugins.

• I don't see the Twitter API plugin as a direct correlation to the Wire plugin. This is why having it bound to the Wire feels so dirty.
• Would we want the Facebook API plugin to do the same thing? (ie, default to updating FB status when someone posts to the Wire?) What about LinkedIn and Four Square?
• API plugins should be like libraries. The library shouldn't have hard-coded info about who might call it.
• It feels dirty to establish a loosely coupled system for pushing to Twitter, then to ignore it with the only bundled plugin that sends tweets.

cash wrote on 41450285-09-01

How about this:

• we add the concept of a status update to Elgg (the profile plugin already tries to pull in the latest status update from the wire)
• The wire emits a status update plugin hook
• The twitter api plugin listens for the status update hook

This way the plugins do not know about each other.

brettp wrote on 41451228-03-08

Since the profile plugin is already pulling status information and that's the primary concern for this ticket, I'm alright with what Cash says. It feels better to me because it's the same push concept (content -> API).

ewinslow wrote on 41451649-11-24

I'm a bit confused. Isn't the wire just Elgg's implementation of status updates? Why do we need a hook for this? I'd rather rename the subtype to status if that would add clarity.

Brett, if I understand you correctly, what you are suggesting implies that the content plugins would eventually know about all possible external services that could accept their content (a potentially infinite number). But external services generally only support a finite number of content types. It makes more sense to me for the content plugins to be agnostic to which of the infinite possible external services are available, and for the services' API plugins to be able to listen for the known, finite set of content types they are capable of handling, at least by default. That definitely means that yes, the facebook api plugin would listen for wire posts and post them as statuses to facebook. It also means it would listen for creation of bookmarks and post them as links, for blogs and post them as notes, etc.

I realize that there may be cases where a plugin author would want to push an unsupported content type out to an external service (e.g. bookmarks to twitter), but that is a special case and the API we provide is for those cases.

At least, that's how I think it should be. This will be my last post since I don't want the conversation to drag on indefinitely.

cash wrote on 41452515-02-05

We use the wire a lot at APL and it is rarely for status updates. I don't think renaming the subtype is a good idea.

This is what I was trying to say:

• There is already a notion of a status in Elgg due to the profile plugin pulling in the view profile/status. In the past, there was an actual status plugin that provided a widget for setting your status.

• The wire is one possible way to set a user's status. As such it could trigger a hook like this:

  $params = array(
  'user' => elgg_get_loggedin_user_entity(),
  'origin' => 'thewire',
  'text' => $post->description,
  'url' => $post->getURL(),
  'object' => $post,
  );
  elgg_trigger_plugin_hook('user', 'status', $params);

• any number of api plugins could listen for the 'user', 'status' hook and do something with the content.

If I wanted to, I could write a new status plugin like the old one that is explicitly for setting status. Or I could write a plugin that grabs new bookmarks and sends a status update: "Cash just bookmarked at elgg.org".

Another alternative is to not have the api plugins know anything and require glue plugins. The twitter api would provide a generic hook and I have to write a glue plugin that listens for wire posts and sends them to the twitter plugin through the hook. I think this is generally how it should be done unless we know of a really common usage like this twitter example.

brettp wrote on 41453221-10-03

A glue plugin was the original plan we had for the Twitter API and Wire rewrites. We merged them for simplicity since it was aimed at the SAS market. For this, let's agree on introducing the status system with the Wire and Profile plugins, and binding status updates to the supported API plugins with an admin option to disable. This will be Twitter and Facebook right now.

cash wrote on 41480776-09-12

Fixes #3204 adds hook trigger so that wire sends out status updates
Changeset: 6eadb67