Alright, so I'm trying to go about creating a multi-platform chatbot type deal.

Last night I was thinking about it and I had the idea of creating a root library that does all the heavy work, and takes an IMessagingContext which would provide a context to actually send messages.

So basically, to allow the chatbot to speak on platform X, one would simply need to create a class XMessagingContext that implemented the interface, and send that class to the bot where it would then do all the work of actually determining what to say and such.

Makes sense.

The problem I ran into is how to design the interface so that it would be most effective.

It needs to support multiple types and levels of messages.

That is, direct messages to other users, global messages, etc.

So, for example, the IrcMessagingContext would support sending direct messages to other users.

GetMessage(param1...)

The problem is, do I create methods for IMessagingContext.SendDirectMessage(string user, ...), IMessagingContext.SendGlobalMessage(string target, ...), etc.

Or, do I create: IMessagingContext.SendMessage(MessageType type, string target, ...).

If it where, me, I would just get the message.

Where MessageType is an enum with Global and Direct.

What do you mean?

The wrapper should manage that. The wrapper should structure direct/global.

You shouldn't rely on the chat system to use @ to ping.

Well the bot itself wouldn't

Oh, OK.

The IMessagingContext would.

I don't know.

That's what I mean. The wrapper should determine how to send a direct message.

So the IrcMessagingContext would implement code that would then send a directed message. The bot would simply call IrcMessagingContext.SendDirectMessage(string user, ...).

One possibility is to create a wrapping type sort of thing.

You request a message from the bot, and the bot returns a type that contains the message, how to send it, and other relevant detail.

Since they should be immutable, a struct should be OK, as long as they are small enough.

Isn't the expected limit for a struct 16 bytes, or something?

Even though I wasn't invited which totally hurt my feelings, I'd go for SendGlobalMessage() and SendPersonalMessage().

or however you name it

@Hosch250 Yeah.

If you use an enum, you will just do the same stuff through a switch in that method

@JeroenVannevel Then the issue becomes, how do I send a message with different levels? Do I create a MessageLevel enum and add each level to it, and let the programme decide how to send it?

level how? What's a level in this context?

@JeroenVannevel That's what I was thinking. I was thinking they were disparate enough that it would be permissible for them to be separate methods.

@JeroenVannevel Important, Critical, Normal, etc.

I don't see why severity is relevant to the receiver

Those are separate things

Just add an argument Severity?

Well should it even care about severity?

Or should I leave it up to the IMessagingContext to handle that?

... I don't know, you said you want to be able to give a severity to a message

Severity is just a property of a message

Well that was part of the original idea, but I'm not sure if it's a good one.

Because I also want to be able to provide the bot with multiple IMessagingContext objects, so that it can post to multiple locations at once.

I.e. it could post to a SqlMessagingContext, a FileMessagingContext, an IrcMessagingContext, a StackExchangeChatMessagingContext, etc.

All from a single instance, rather than having to create four instances of the bot to do all that.

You just create implementations to handle all those services and add them as default stuff to your library. No problem there

The severity thing isn't a problem either. It's just like any other property of a message -- like body, timestamp, user, etc

I don't see why that causes confusion

room topic changed to Room for EBrown, Hosch250, Mat's Mug, Jeroen Vannevel: (no tags)

Well I'm more-or-less curious as to whether or not I'm overcomplicating it

I want the bot library itself to fetch and parse messages.

And then you just shove in a context for it to send them to.

The idea is straightforward

sounds a lot like the decorator pattern

I suggest you start implementing from this raw idea and see where it gets you

If applications could be perfected by design beforehand, everybody would write flawless code

You'll notice soon enough if you get stuck once you've got a few of your contexts done

Why don't you write a sample wrapper first and see what you need?

I think that's what I might do.

You can pretend your library exists by creating an interface and just calling the interface.

After you get your interface built, build the library around your interface.

@EBrown If I were you, I would have the wrapper pass the messages to it.

@Hosch250 What do you mean?

The library itself shouldn't fetch the messages.

The wrapper should be responsible for fetching them and sending them.

It should only take input from the wrapper and output to the wrapper.

Otherwise, you will need to modify the library to fetch the messages from every system you want it to work on.

Well no, that's not how the library will be doing it.

I suppose I could create an IReadableMessagingContext and IWriteableMessagingContext, where IReadableMessagingContext is IRC client getting messages from users, then IWriteableMessagingContext is the bot sending messages to the IRC client.

But some of the messages will be triggered by events.

I.e. a commit posted to GitHub.

Which will post back to a REST API endpoint, that will parse the commit details and add a message to a SQL table for the bot to pick up.

Then the bot will forward that message to whatever location it belongs at.

Doggy Duga-style

Sorta, yeah.

Except with the ability to respond to user input.

Duga has limited ability, but Simon keeps it off most of the time to prevent attacks.

I wouldn't make it a global feature, it would have to be turned on/off on demand.