0

I have a C# .NET app that downloads a users Tweets using LinqToTwitter. This is for TV broadcast - the client wants to show Tweets on air. We have two other apps that need to access these tweets. One is a C++ app and one will use MS Script Host. These two apps don't run at the same time - it's one or the other.

My question is, of the many ways to share this data, which would you choose?

DataBase - Like MySql. This was my first choice. But then it seemed like overkill for the 10-20 tweets they would get per day.

Streaming - Like TCP or named pipes. This would involve some type of protocol. Like "Give me the last 10 tweets..."

Xml - Store the data in a file all programs can access. Simplest, but just doesn't feel right for some reason.

Memory Mapped IO - I think this would require a COM library for the scripts to be able to use it

There are others. Just curious what you would use. I am the only programmer in a small company and don't have others to bounce ideas off of.

Thanks.

closed as too broad by amon, gnat, superM, GlenH7, user40980 Feb 18 '14 at 2:24

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • If you are looking for shared storage, another option might be Redis (in-memory store with client/server protocol). If you decide to stream, might want to consider 0mq instead of straight up TCP. Or possibly even something like RabbitMQ – DXM Feb 5 '14 at 17:17
  • Redis looks cool. Too bad it's not too Windows native. – Johnny Mopp Feb 5 '14 at 20:20
2

I vote for a database. Any concerns around locking, concurrent access, persistence etc would be dealt with by the database, and more clients can be added without impacting the others. The architecture would then be;

                              +--> Reader A
                              |
Data Extractor --> Database --+--> Reader B
                              |
                              +--> Reader C

It would also be straightforward to run reports on the tweets later e.g. stats per day.

  • Thanks for the input. DB was my first as the most robust. – Johnny Mopp Feb 5 '14 at 19:35
1

A database would work well. If you are concerned about deploying the database, or licensing, you might want to look at something built into the operating system, such as MSMQ (called Message Queuing in the latest documentation), or the built in database, ESENT:

  • Thanks. I am unfamiliar with ESENT and am researching it now. – Johnny Mopp Feb 5 '14 at 19:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.