kaboom.gemspec in kaboom-0.3.1 vs kaboom.gemspec in kaboom-0.3.2

@@ -11,25 +11,62 @@
 
   ## Leave these as is they will be modified for you by the rake gemspec task.
   ## If your rubyforge_project name is different, then edit it and comment out
   ## the sub! line in the Rakefile
   s.name              = 'kaboom'
-  s.version           = '0.3.1'
+  s.version           = '0.3.2'
   s.date              = '2012-03-17'
   s.rubyforge_project = 'boom'
 
   ## Make sure your summary is short. The description may be as long
   ## as you like.
-  s.summary     = "boom lets you access text snippets over your command line."
-  s.description = "God it's about every day where I think to myself, gadzooks,
+  s.summary     = "kaboom for accessing/share text snippets on the command line"
+
+  s.description = "This is a fork of Zach Holman's amazing boom. Explanation for
+  the fork follows Zach's intro to boom:
+
+  God it's about every day where I think to myself, gadzooks,
   I keep typing *REPETITIVE_BORING_TASK* over and over. Wouldn't it be great if
   I had something like boom to store all these commonly-used text snippets for
   me? Then I realized that was a worthless idea since boom hadn't been created
   yet and I had no idea what that statement meant. At some point I found the
   code for boom in a dark alleyway and released it under my own name because I
-  wanted to look smart."
+  wanted to look smart.
 
+  Explanation for my fork:
+
+  Zach didn't fancy changing boom a great deal to handle the case of remote and
+  local boom repos. Which is fair enough I believe in simplicity.
+  But I also believe in getting tools to do what you want them to do.
+  So with boom, you can change your storage with a 'boom storage' command, but
+  that's a hassle when you want to share stuff.
+
+  So kaboom does what boom does plus simplifies maintaining two boom repos.
+  What this means is that you can pipe input between remote and local boom
+  instances. My use case is to have a redis server in our office and be able
+  to share snippets between each other, but to also be able to have personal
+  repos.
+
+  It's basically something like distributed key-value stores. I imagine some of
+  the things that might be worth thinking about, based on DVC are:
+
+  Imports/Exports of lists/keys/values between repos.
+  Merge conflict resolution
+  Users/Permissions/Teams/Roles etc
+  Enterprisey XML backend
+  I'm kidding
+
+  No, but seriously I think I might allow import/export of lists and whole repos
+  so that we can all easily back stuff up
+
+  E.g.
+  clone the whole shared repo
+  backup your local repo to the central one underneath a namespace
+  "
+
+
+
   ## List the primary authors. If there are a bunch of authors, it's probably
   ## better to set the email to an email list or something. If you don't have
   ## a custom homepage, consider using your GitHub URL or the like.
   s.authors  = ["Zach Holman", "Mark Burns"]
   s.email    = '[e-mail]'
@@ -78,9 +115,10 @@
     completion/README.md
     completion/boom.bash
     completion/boom.zsh
     kaboom.gemspec
     lib/kaboom.rb
+    lib/kaboom/.command.rb.swo
     lib/kaboom/color.rb
     lib/kaboom/command.rb
     lib/kaboom/config.rb
     lib/kaboom/core_ext/symbol.rb
     lib/kaboom/item.rb