You’re right about dependencies in cabal… I couldn’t install Yi Editor through Cabal… But i was in windows, maybe i’ll have more luck in Arch.

Cheers, and keep the good work!

Essentially all the original plans remain in place, including eventual revenue positivity. Only somewhat slowed down due to demands of day job/pays-for-rent gig, where I will have a very busy next two months.

My tentative plan is to go back to giving patch-tag, and the happstack ecosystem in general, some love in october or thereabouts.

Meanwhile, if anybody in the community would care to have a whack at adding features I will gladly support them. I haven’t done much outreach on the open-sourcedness because of the time factor (in fact I have blocked reddit and hn in /hosts ) — but I continue to be present on email and the the patch-tag googlegroup.

(I wouldn’t worry about patent trolls, honestly, but if you are– may I suggest the Ms-RL or Ms-PL? I think the GPL has become worryingly bloated and the Ms-RL and Ms-PL are well written and easy to read, modern alternatives. But that’s just my opinion and I’m not a lawyer…)

As for sandboxing ssh/linux admin issues: have you considered making the default send-only push? You can darcs send to an HTTP POST (in any 2.0+ version of darcs) in addition to polling an email account. Sends can be signed with SSH or GPG keys (so you don’t need to emulate SSH, you just need to be able to check key signatures). The most complicated part is currently that for both HTTP POST (and email) you need an email parser library that you can trust– at the very least it has to support extracting mime attachments.

(I have small bits and pieces of code written for my own “darcsforge” where my plan was to do only send-only pushes and have a nice patch queue interface attached to that so that everyone uses the same darcs send, and that’s the only vector for new patches. Authentication would be handled by signatures, and patches from unauthenticated sources and/or patches that fail darcs test can wind up in the same patch review queue. I think its a pretty nice setup conceptually, I’ve just been slow to finish building it in my own case.)

As for license suggestions, it seems like whatever you decide, the more well known licenses (GPL and BSD3) may be a better bet for sheer recognition. Going for BSD3 simplifies having bits of patch-tag be spun off into independent libraries on Hackage (seems like BSD3 is a preferred license for libraries).

As for the name, you have both domains; what’s the harm in switching now?

I hope there’ll be some good cross-fertilisation or hybridisation between patch-tag and darcsden.

You asked for license suggestions; mine is GPLv3 or later as the default, because it gives you best protection against patent trolls and it seems unlikely that reusing this software in closed-source products is a priority.

1. rollbacks – the fact that you can rollback by hex editing some files is purely by chance.. it was never intended to be used that way. The proper way to rollback is to restore an old back. How would you rollback using something else, such as SQL, etc ?

2. events being lost due to OOM killer – this seems unlikely. The call to ‘update’ will not return until the event has been written to disk. Personally, I have never seen macid lose an event, and I have never received a reproducible test case. The only except to this is if you call error/fail inside your update function. That, however, results in a pretty fatal, repeatable error, not ‘random data lose’. The fail/error issue will be addressed in 0.7. For now, just don’t do that

The memory usage and documentation issues will be addressed in 0.7. I also plan to add facilities to make it easier to examine and modify your live database (similar in spirit to using a command-line tool like mysql-client to mess with your sql database).