On 05.08.2009, at 12:03, Ceki Gulcu wrote:

Hi Joern,

TwitterAppender does make sense.

As a use case, imagine an application problem represented by a logging event of level ERROR. The logging event is sent to TwitterAppender which tweets (posts a tweeter message) under the account of Alice, a dedicated (non-human) tweeter user. Relevant system administrators, followers of Alice, would see her tweets and take whatever necessary steps are required to respond to the error message. They could do so using a tweeter client on a smart phone, for example "tweetie" [1].

Best of all, there's another application for the iPhone called Boxcar [2] that pushes @replies, meaning that a message box pops up on the phone and an (optional) sound (or vibration if muted) is played when a reply is received. So it would probably make sense to send those messages as @replies to users listed in the appender. This would reduce the number of available characters, though.

You could prevent flooding by limiting the number of tweets per time frame, say at most once an hour. I actually have code lying somewhere which does this using a sophisticated algorithm. Consider flooding as a solved problem.

Evaluators, in particular JaninoEvalurators, could be used to filter out certain messages from triggering tweets. Tweets of confidential log messages could be avoided assuming the said log messaged contained a special marker, say CONFIDENTIAL.

Another way that I forgot would be a twitter account with a private timeline. Those are not available for searching and can only @reply to people that are following it. Following must be accepted by the account. I think this would be sufficient for most cases but something like a CONFIDENTIAL marker does also make a lot of sense. This would simply be configured "around" the appender, right?

The contents of the tweets could be formatted using a PatternLayout similar to the way SMTPAppender formats the subject of the outgoing email message.

This sounds very good. The only problem I see is that the message would have a variable length, i.e. 140-username.length()-2, in case of @replies. Those are much more useful than just a status-update, though, due to the mentioned push-functionality and special sounds played by desktop applications.

How about building a prototype of TweeterAppender?

I could do that but I'm pretty occupied at the moment. Twitter4J is dead-simple, though. The dependency is <dependency> <groupId>net.homeip.yusuke</groupId> <artifactId>twitter4j</artifactId> <version>[2.0,)</version> </dependency> And sending a status update is done like this: Twitter twitter = new Twitter(twitterID,twitterPassword); Status status = twitter.updateStatus(latestStatus); System.out.println("Successfully updated the status to [" + status.getText() + "]."); The twitter instance would only be created once and is thread-safe. I think all that would be needed by a TwitterAppender would by String username; String password; String users; // ,-seperated list of twitter usernames to use for @replies List<String> userList; // users parsed from users-variable after setUsers has been called The only problem I see is the fact that Twitter does not allow you to update the status to the same text. If the appender would try to append "A message" twice it would only be appendet to the timeline once. The easiest way to circumvent this would probably be an initial message like "<context name> is about to tweet a new message:" before sending the actual message of the event. Joern.

[1] http://www.atebits.com/tweetie-iphone/

Joern Huxhorn wrote:

...

Hi guys, I'm using Twitter4J on another small project and I was wondering if a TwitterAppender would make sense. I'd obviously only do something in case of an error to prevent too much tweets followed by a ban of the user. I would have the benefit (at least foe ppl like me that get tweets pushed to their phone ;)) that I would get informed immediately if something really bad happens. I'm just brainstorming here but I'd like to hear other ppls opinions on the case. The Appender would have a dedicated Twitter user. Twitter user and password would be set in the config. Additionally, a list of Twitter usernames would be provided. Those would receive a reply (or a DM?) in case of an error. Some questions that jump to my mind: What should the actual message contain? We only have 140- username.length()-2 characters. Messages shouldn't contain anything confidential... Messages must not be the same all the time. They need to differ, otherwise they will be ignored by Twitter. How should flooding be prevented if the app keeps producing errors (this would ban the twitter user, otherwise) Ideas, Suggestions, Bashing? ;) Joern.

[2] http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=321493542&...

On 06.08.2009, at 15:15, Ceki Gulcu wrote:

...

...

How about building a prototype of TweeterAppender?

Since you submitted the idea, I was assuming that you were also volunteering to do the implementation. Did I somehow misread your intentions?

No problem, I'll do that. But I'm pretty sure I'll need your help at some point ;) Joern.

-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev

On 06.08.2009, at 15:15, Ceki Gulcu wrote:

...

I think this would be sufficient for most cases but something like a CONFIDENTIAL marker does also make a lot of sense. This would simply be configured "around" the appender, right?

Around the appender? I am not sure what you mean, but among the various data you pass to the appender, you could pass the name of the marker (a String) that triggers confidential treatment.

What I meant were filters. Sorry about using a rather confusing description. I've never used filters before but it seems like a MarkerFilter would be the "right" way to prevent the tweeting of confidential event messages. Joern.