@jackyalciné

Got an app idea or need some coding done? I can help! Learn more about how you & I can work together.

Ambitions for Wintermute

Explaining my ambitions for Wintermute.

:book: wintermute :bookmark: long-reads, development, affirmation :clock7: :clock3: about 11 minutes

From naming to thinking, Wintermute is a fickle project. One so complex, I legitimately forgot my objective whilst working on it. This entry is going to serve as a means of me keeping track of the end goal. If there’s one thing that happens with passion projects, it’s definitely the overwhelming amount of emotion one can throw into it.

What’s Wintermute Capable Of?

Wintermute is an attempt to build a “universal” communication platform for existing and future bits of software I find and plan to build. The idea is that if it can communicate over a network or between processes on a local machine; Wintermute can use it and make it work in its favor, whatever it may be. The core library is meant to be the foundation that hides a lot of the platform-dependent nuts and bolts and make things work like remote procedure calling, extension support & discovery and whatever that should be handled by the core instance of Wintermute.

From there, we only can go up in terms of extensibility. The idea is to have plugins, who consume data collected by Wintermute or add to the pool of data that Wintermute has. It’s very binary because things tend to be a lot simpler for computers that way. It, in my opinion, will reduce complexity when it comes to working with more lower level pieces of hardware like the Spark line of tools or the Raspberry Pi. You know, for that home automation and wearables tech stuff everyone’s raving about.

Spin, my Pi, spin.

There’s a few things I want Wintermute to do. Having it written out makes it more of a declarative thing and gives me a bit of direction as to what Wintermute should be capable of doing. Mind you, I’m open to suggestions for the list, just be willing to provide a solution for execution or implementation.

Does an Internet

All in all, I want something similar to, if not exactly like, Jarvis. It’s overly ambitious and on that reason alone is why I’m eager to continue hammering at this project. If anything, I’ve learned time and time about continuous deployment, having a strong test suite, a maintainable repository and the benefits of composition and abstractions in software just from this project3. And this is just the crux of it.

What’s The Approach?

When I first started hammering out the code base for Wintermute, I used a shit ton of tools to make it quick ‘n’ dirty. Qt, Boost, CMake and a lot of battle-tested libraries to just get my ideas into code quickly. As time went on, I noticed that I couldn’t just have it running only on my laptop. I’d want to have certain instances of Wintermute running on an in-house box, some boxes that are permanently connected and others running on my phone and other bits of embedded hardware. I took some time to re-think the approach and decided on tearing down all that I had to rewrite Wintermute as a shared library.

From there, I also decided to reduce the number of dependencies that Wintermute had. I dropped the Qt library in favor of using the standard C++ library. This gave me a chance to revisit some of the more disguised concepts in C++ like handling event loops, or fiddling with dynamic library loading. What I realized is that I would have to handle a lot of cross platform issues when building out Wintermute for other devices4. At first, I thought this to be a super big and annoying challenge, but I think that this’ll allow me to have focused builds of Wintermute and iterate accordingly for each platform. It’s not like I’m rebuilding streams in C++, though.

So, What’s the Library Doing?

The core library of Wintermute, libwintermute is meant to provide the following:

Does an Internet With the preceding, (hopefully) any application can then utilize Wintermute’s base functionality and build a tool that’d feed back to the connection system of Wintermute. At least, that’s the plan. Right now, I’m juggling between the set up of ZeroMQ for Wintermute and crafting an abstracted (enough) event loop system for Wintermute which right now is heavily influenced by libuv. I try to work as transparently as possible (you’ll even catch me force pushing, a lot).

  1. As does any developer who realize ANYTHING can be made to be programmable eventually. 

  2. If you don’t test, you’ll NEVER KNOW! :fireworks: 

  3. And that’s the tip of the iceberg. 

  4. My goal is to have the core C++ library for Wintermute working on Android, Ubuntu and Raspbian.