Authors CurseForge

TweetCraft, a WoW twitter client (if that name wasn't obvious), uses LibDataBroker for both a launcher and for storing tweets.

I'll post on the wiki on github with our data specification. We have a library that wraps it pretty nicely but I think it would be cool to share the raw spec if people want to work against that.

Quote from Mogonar

TweetCraft, a WoW twitter client (if that name wasn't obvious), uses LibDataBroker for both a launcher and for storing tweets.

I'll post on the wiki on github with our data specification. We have a library that wraps it pretty nicely but I think it would be cool to share the raw spec if people want to work against that.

I'll try to be as nice as possible in saying, that the way you are using the library shows :

a) You are using it for a purpose it was never designed for and in a way that totally goes against the "spirit" of its logic.
b) You don't care that you are breaking the upgrade path and/or the implication of callbacks for the addons embedding LDB.
c) You really don't understand how lua works.
d) All or some of the above.

For the love of all that's good and holy, please rethink your implementation (to say the least).

Quote from Tristanian

I'll try to be as nice as possible in saying, that the way you are using the library shows :

a) You are using it for a purpose it was never designed for and in a way that totally goes against the "spirit" of its logic.
b) You don't care that you are breaking the upgrade path and/or the implication of callbacks for the addons embedding LDB.
c) You really don't understand how lua works.
d) All or some of the above.

For the love of all that's good and holy, please rethink your implementation (to say the least).

Remove the first part of a.) as it was specifically designed to be used an darn near any way that anyone wanted to create a spec for (even a non-published spec). Can't comment on the rest as I haven't looked at the code but we don't want to start spreading about the phrase "using it for a purpose it was never designed for" when talking about LDB.

And again I see Arrow being a complete arsehat about things.

No, a) is correct. The modifications they are making fairly well prove that they want to do something different than what LDB was designed for (albeit similar). The long and the short of it is simple... DO NOT MODIFY A LIBRARY THAT IS NOT YOUR OWN. If you want to take LDB to make some other lib that does what you want, fine, but modifying the library at run time proves fairly damn well that you don't get the way libs work in wow and what modifying the lib will do to other users of the lib... which proves why you SHOULDN'T be modifying the lib.

Quote from Tekkub

No, a) is correct. The modifications they are making fairly well prove that they want to do something different than what LDB was designed for (albeit similar). The long and the short of it is simple... DO NOT MODIFY A LIBRARY THAT IS NOT YOUR OWN. If you want to take LDB to make some other lib that does what you want, fine, but modifying the library at run time proves fairly damn well that you don't get the way libs work in wow and what modifying the lib will do to other users of the lib... which proves why you SHOULDN'T be modifying the lib.

They are actually modifying the lib at runtime? O_O That's a nono.

Yes, that's why we're all pissed off. They didn't fork it and make their own version, they didn't submit a patch to me... they just bruteforced what they needed into the library when their addon loads, breaking the embed upgrade path and pushing any potential bugs in their implementation onto every other addon that uses LDB.

And the real pisser to it all is they're using LDB as some sort of data store (which is why they needed the modifications). No, I'm not saying they're using a DO as a data store, they're using the LIB as the data store. Why the hell they're not just using a damn table is beyond me.

All I can guess is they saw that it had callbacks and they liked the callbacks, so they wanted it to do callbacks for things the way they want.

We're fixing this. We'll stop modding the library at runtime. We'll move those functions off the addon itself in the short term but longer term I want to figure out the right design for what we're trying to achieve.

I prototyped and designed this but I didn't implement it myself. I'll go thru what I wanted and how I though LDB could support that. I'd appriciate any input you have about how it was done and how we should do it. I'm happy to admit that I'm not an expert Lua programmer. I spend most of my time in C# and .Net where I consider myself an expert.

The idea was that addons that want to autotweet can simple fire the tweets off using LibTweetCraft and the actual TweetCraft addon (or some other addon that knew about our data spec) could grab them and either 1) display them in game or 2) get them saved as SavedVariables for some client app to pick up. I can see the value of having other addons that do #1 but the chances of #2 are probably pretty remote.

Originally, I had thought that we could create two data objects "IncomingTweets" and "OutgoingTweets" that contained as one of their fields a list of tweets. If you want to display tweets, grab one or both of these and go nuts. If you want to send tweets, either use LibTweetCraft as a easy API around the OutgoingTweets collection or add them yourself. Either way an addon like DBM or BigWigs that wants to add support for tweeting boss kills could just embed LibTweetCraft and fire away even if TweetCraft itself wasn't there to get the message and actually send them.

I decided not to go with the list object plan and went with the "data object per tweet" plan. In retrospect, this was probably not the right move but we can make it better in the next release.

I thought that LDB would be the right way to allow other addons to get a hold of our information about tweets that have been brought into the game and figured that we could just build the TweetCraft front end to run off the same data in the same way I envisioned a 3rd party addon would.

We have a bunch of fixes we want to do around other things and I'll make sure we stop modding LDB as a part of that release.

Interesting addon, more in how they worked around the fact WoW is sandboxed.

http://tweetcraft.codeplex.com/

http://blogs.msdn.com/coding4fun/archive/2009/07/02/9813390.aspx

I wonder what Blizzard would think of this.

How is that interesting? Addons have used reloadui many times before to get data in or out. None of them took off because it's a huge pain in the ass (and their users are bitching about that more than anything else).

I wonder if you have the guts to run a installer from an unknown source that targets WoW

The fact it requires to reload the UI for every update, is enough for me to avoid it entirelly, yet even try it. Call me back when WoW supports live updating of remote data (which it never will .. except the /gm frame).

Quote from dranor

I wonder if you have the guts to run a installer from an unknown source that targets WoW

You could download the code and compile it byself after looking through it. But really... /rl isn't an option (and RSS is much more usefull than Twitter IMO)

Quote from Xinhuan

It isn't really hard or performance hitting for wow to run wow in fullscreen maximised windowed mode without the borders (the option is in game) and just alt-tab to twitter. There isn't any delay in alt-tabbing since its all windowed.

I lost at least 10-15 FPS running in a maximized window versus fullscreen under 32-bit WinXP. Under Win7 x64 RC1 on the same hardware there is no performance loss. This is the main reason I've been using Win7 as my primary OS lately (alt+tabbing out during the lulls in a raid is essential for staying awake :p).

And yeah, using /reloadui to get external data into WoW is retardedly clunky IMO.