This project is read-only.

Why no parameters to Trigger/Perform?

Mar 13, 2012 at 4:40 AM

I'm very new to this project but keen to integrate it with my automated time tracking application Crisply.

The first thing I wanted to do was setup a directory watcher and have it post change notifications to Crisply.  This was trivial but ultimately almost useless.  I really don't want to have to setup a unique watcher for every dir.  I'd much rather have a single watcher on the parent dir and then pass the changed dir(s) to the reaction (in this case a cmd script that invokes curl).

What's the rationale for not having parameters between trigger and perform?  Is this on the roadmap?



Mar 13, 2012 at 5:49 AM

This is a great question, and one that we have thought about a lot. I've got a lot to say on the subject, so give me a few days and I'll have an answer for you. :)

Mar 13, 2012 at 6:30 PM

I see it as a huge limitation of Mayhem. There must be some form of context passing from an Event to ITS Reaction. Would love to hear resolution on this.

Mar 14, 2012 at 7:49 AM
Edited Mar 14, 2012 at 7:51 AM

I've gotten my response to this question up (it's a really common question). The post gives more insight into Mayhem's core than we've talked about so far, so I hope it sheds some light on the issue.

Mar 15, 2012 at 3:33 AM

Thanks for the response Eli.  I fully appreciate the balance you've struck.

I certainly agree that passing a generic string parameter is going to cause more problems than it solves.  A string will cause developers to serialize more complicated things and then interpret them.  This can only result in strange, incomprehensible errors for end-users.

I suspect the pent up desire for a system wide events and automation mechanism like OS X Automation.  Despite several fledgling attempts Microsoft has yet to deliver anything comparable.

My concern is that your application is too geeky for the common user and too simple for the power user.  It's obviously early but in addition to a rich library of events and reactions you'll want to make sure the end-user experience is truly "Mom friendly."

I'm sure you've seen  Some mechanism for sharing recipes will help adoption a lot.  Once you have sharing I suspect you'll want some abstractions around various events and reactions.  For example, watching for directory changes on a specific path isn't really something you can share.  Watching my documents folder or the MSN IM log folder is something that will just work.

I'll try my hand at writing some events and reactions soon.  I want to integrate it with my time tracking application which is all about automatically creating timesheets from user activity.

Mar 15, 2012 at 4:43 AM

Michael, I appreciate your comments. We definitely have a lot of work to do to make this as simple and powerful as we want it to be. Part of this will be from radical changes the web experience to find modules (and what people have done with them / how they were configured), as well as application changes; better ways to organize the ones you have installed, an easier to navigate interface, etc. We are just at the beginning of this project and have a ton of work to do.

I think the level of “geekiness” required will also drop significantly when we have more people like you who see potential and step up to write modules. Personally, I see the modules that we have written purely as examples of what Mayhem is capable of. Now it’s up to the world to write the really intuitive ones that are truly user friendly.


Mar 15, 2012 at 5:21 AM


I worked at Microsoft for 16+ years.  You know what that means: I'm going to get on my high horse and pontificate.  Indulge me and I'll buy you a beer when I'm back on the left coast.

tl;dr  The "world" is not going to create your platform for you.  You've started and now you have to finish or this will remain a curiosity.


Developers don't create platforms for you, they'll come to you when you've created a platform for them.  By platform I mean an application that has lots of users and from which developers can derive value by integrating with their systems.  

When you look at Mayhem with a very jaundiced eye, the utility is not in the system.  Most competent engineers could build such a system (even if nobody else has).  It's not even in the code that knows how to get the weather or post to Facebook.  Again, most competent engineers could do that too.  The value of what you've built is that you took what most competent engineers could do and you did it in a consistent and valuable way.  That's how you get to critical mass.  Keep building user friendly modules that do what users care about.  At some point you will indeed reach critical mass.  Users won't be able to imagine how they used computers without Mayhem :)

Until you get to that point Mayem will remain in the domain of power users and hackers.  To get to that point you're going to have to build enough of the core events and reactions for those users, not developers, to derive utility.

Obviously it's going to take a while.  The compromise you've taken is the right one.  Build a system (not quite a platform yet) that is good enough for power users and compelling enough for developers and, this is the hard one, will progress towards a real platform.

The easier it is for a developer to build a module for your system the better.  Don't assume that developers are familiar with .NET.  I actually worked on Avalon (WPF) but it's been a long time and has changed enough that it would represent real friction in the way.  When I look at the interop between systems I don't want embedded assemblies or DLLs.  I want the lowest possible common denominator.  Michael's rules of component software state that there are really only three good ways to communicate between components:

  1. Files.  Files are good.  Easy to debug, easy to test and really easy to make work with existing applications.  Files decouple events and reactions and that's a very good thing.
  2. Command lines.  Command lines aren't better than files but sometimes you really want to make something happen now and/or get some confirmation of success.  Invoking an external command with command line args and stdin is probably the most entrenched pattern of component software.
  3. HTTP.  If you can't use a command line to invoke an app it's because there's a network involved and probably more async.  RESTful calls over HTTP are the only way to go.  They're even appropriate on the same machine.

Combine those thoughts with a manifest that lets anyone (not just a programmer) describe a settings form (say in HTML) and I think great things would happen.

The good news is that you're pretty close.  It would obviously be trivial to create an event that watches for a particular pattern of file as an event and you already have a command line reaction.

Mar 17, 2012 at 4:41 PM

I totally agree with Michael. You cannot leave it to developers / enthusiasts to make your product being used more. I am not saying this is not a valuable way to get feedback and plugins created for Mayhem (otherwise, I would not have been toying with it for the past two hours)... but you should not rely on it : you have to accompany developers so they use your software.

And for that, I know of only three solutions: documentation, documentation, and documentation. Yes, I know, it must be boring for you to explain where we should put the .mayhem add ons, because that might seem absolutely obvious to you since you have been working on it for long. But believe me, it is necessary... I am a seasoned developer (MVP) and the structure of the Mayhem program directory does not make it obvious, and there is no indication on the add on download page. In addition, I searched for "add on" / "addon" / etc. in the FAQ, and nothing helped. Of course, if I am motivated enough, I will search by myself and put the files in different places, see how it reacts... Maybe even read the source code to try and understand where they should be put... But explaining this right away would spare developers some time, and make them more likely to program against Mayhem.

Another thing on the same subject: the documentation for Visual Studio is a nice effort, but you are missing a few things to make it usable. Namely, you explain very well how to create a reaction and an event (and it is a great idea to use a real-world code), but you stop before the end : what comes out of the compilation ? Where do we put it so it is taken into account by Mayhem ? What is the complete list of WPF standard forms we can count on ? Is there an API reference somewhere ?

As Michael said, you are quite close to what is needed. But what is missing, in my opinion, makes the difference between "spending an amusing afternoon playing around with it" and "getting massive developer involvement".

My personal reaction to experimenting Mayhem is that I wrote two messages (this one and another one on speech recognition not working), and I will be back in a few weeks to check for answers. My using Mayhem and developping add ons will entirely depend on them. Please do not take this as a threat or anything bad-tempered: I am simply describing (with my expressions, which may not be well chosen, as English is not my native language) what - I believe - is a standard developer's reaction to a project.



Mar 17, 2012 at 8:44 PM

My lack of a response right away to Michael was because I absolutely agree with what he said. That is why we are still actively developing it, writing modules and pushing it forward. We haven't even really gotten started with our push of this into the world.

In terms of where to put the addon, that is a good point, I could see how that could be confusing. Just open the .mayhem file that you download from the web. The file type is associated with Mayhem and it will launch the installer for that add-on and put it in the right spot for you.

In terms of an API reference, check out the documentation page in a few days. Documentation is definitely one of the biggest things we need, and it is easiest to expand when people ask the questions that we need to answer. Obviously we will try to predict these questions as well.

In terms of stopping before the tutorials are actually complete, they are missing a final complete code listing. In terms of where to put the code so it appears in Mayhem, apparently that is only mentioned in the guide for creating a reaction:

"We now need to build the class library we have created and add it to Mayhem. So build your project, and locate the dll you created in your project’s bin folder.

Locate the main Mayhem directory, if you compiled the Mayhem source itself, then that is the top-most bin folder. If you installed Mayhem from the web, that is %ProgramFiles%/Outercurve/Mayhem. Just paste your dll into that folder."

I will add that to the guide for an event.

On that note, I have created a component on the issue tracker for "Documentation". It would be a great help to log all the things you are hoping for, or are missing on there so we can keep track of them. Also that way, when they are updated you can verify that the changes fully address your issue.

Mar 18, 2012 at 6:18 PM

When adding the hint about finding where to put the dlls, could you please show a complete Mayhem file hierarchy, because since there is a Mayhem directory INSIDE the %ProgFiles%/Outercurve/Mayhem directory, it is hard to be sure you mean the Mayhem directory or the Mayhem/Mayhem one... Particulary since the former does not contain any file whereas the latter does.

And just to be sure : is it normal that there is a "content" subdirectory inside Mayhem/Mayhem? Because this is where the executable is, and that sounds strange to have the addons ABOVE the executable in the tree...

Thanks for your concern with the documentation : I look forward reading the API, and will definitely let you know if I find something still missing, using the issue you created.