Ruwiki 0.8.1 Coming Soon, Ruwiki 0.9.0 Soon After
Tuesday, 21 September 2004
Posted by austin in: Ruby, Ruwiki, comments closed
It’s been several weeks longer than I thought it would be for Ruwiki 0.8.1, but the scope has grown, too. Curt Hibbs asked me to step up my efforts on authentication to make it possible to deploy Ruwiki on RubyForge soon.
Basically, all of the work that I mentioned in Ruwiki Deployment needed to be done, plus work to support authentication on RubyForge, while trying to establish a solid API that won’t need much fixing before the 1.0 release of Ruwiki. This also meant that some of the work planned for 0.9.0, including robot exclusion based on user ID (including the exclusion of certain robots entirely because they are email harvesters).
I hope to have Ruwiki 0.9.0 out by RubyConf, but I have my doubts as I haven’t even finished testing the deployment code in Ruwiki 0.8.1. It won’t be out much longer after that, though. Maybe even during RubyConf.
Minitar, Ruwiki, and Commands
Tuesday, 7 September 2004
Posted by austin in: Archive, Ruby, Ruwiki, comments closed
I mentioned last week that I had detoured into Mauricio’s rpa-base code for packaging code. I was all set to finish the work on a deployable Ruwiki, complete with this code included in the release, when I realised: “that’s dumb.” Why was I going to release something that could and should be an independent library embedded in Ruwiki, when the whole point of the exercise is to make Ruwiki a good RubyGem and RPA package that doesn’t include things which are logically separate.
It wasn’t as if I weren’t going to release Minitar as a separate package; I said that I would, last week. I just realised that doing it earlier was more important than doing it later and getting Ruwiki out quickly. Doing this also helped me find an answer to the next phase of Ruwiki development, too (following the deployment release).
While looking around at options for how to present the UI for the Ruwiki deployment utility and the minitar utility, I looked at the RubyGems code that emulates the cvs command-line in many ways. This made a lot
of sense, to me, so I created CommandPattern:
class CommandPattern
class AbstractCommandError < Exception; end
class UnknownCommandError < RuntimeError; end
class CommandAlreadyExists < RuntimeError; end
class << self
def add(command); ...; end
def <<(command); ...; end
attr_accessor :default
def command?(command); ...; end
def command(command); ...; end
def [](cmd); ...; end
def default_ioe; ...; end
end
def [](args, opts = {}, ioe = {}); ...; end
def name; ...; end
def call(args, opts = {}, ioe = {}); ...; end
def help; ...; end
end
It seems to me that this is exactly the same pattern as I need to deal with for Actions in Ruwiki. Okay, so there are differences -- but not as many as I had initially thought. The amount of code to be reused, to be quite honest, is low, but the concept reuse is high. It's very cool, to say the least.
Follow-up
With the release of minitar, the examples originally given for deployment could become:
% minitar extract ruwiki-0.8.0.tar.gz % cd ruwiki-0.8.0 % ruwiki_servlet
Ruwiki Deployment
Thursday, 2 September 2004
Posted by austin in: Ruby, Ruwiki, comments closed
When Alan originally wrote Ruwiki, he wrote it as a single-user or small-group Wiki clone. When I first started hacking against Ruwiki, I kept it the same. There is increased interest in Ruwiki on large Ruby sites now, as well as interest in having Ruwiki delivered via RubyGems or RPA.
Ruwiki works extremely well under the “unpack and run” model that we’ve delivered it as so far. Unfortunately, when considering how to deliver Ruwiki as a RubyGem (as Mauricio and the RPA team will deliver Ruwiki as an RPA package), it was brought to my attention that the installation is in a central location, and this is not desirable: this means that you could only have one Wiki per machine1 and that the data would be in a location that is less than ideal (under RubyGems, it would be under ${prefix}/rubygems/gems/ruwiki-<em>version</em>/data), making it hard to have a private Wiki on a public server. Originally, I thought this would be a trivial thing to fix, but it isn’t, especially when the goal is to keep Ruwiki as simple as possible for the end user. Solving this installation problem, however, seems to solve other possible deployment scenarios.
The first step is to make it so that one doesn’t even need to have the main Ruwiki programs in the same directory as the Wiki. Some of this has been enabled for a long time, but I’ve never really tested this configuration. I determined that it would be beneficial to have the ability to keep a configuration file separate from the Ruby code.
The Flatfiles tagged format (section!item:value) was ideal for this2, and I generalised it to handle any two-level hash (e.g., { 'ruwiki' => { 'version' => 0.8.1 } }). This became Ruwiki::Exportable; I verified that my implementation was correct and complete by modifying Ruwiki::Backend::Flatfiles and Ruwiki::Page to use Ruwiki::Exportable, and then implemented it in Ruwiki::Config. This required one incompatible change: previously, storage options had been stored like @opts[:<em>type</em>][:<em>name</em>]. While the storage type is still referred to as a Symbol, the options for each storage type are now stored as strings. That is, what used to be @storage_options[:flatfiles][:data_path] is now @storage_options[:flatfiles]['data-path']. Note that the name has changed slightly, too.
The second step is initial deployment. This led me into a week-long diversion into Mauricio’s RPA::Package code, leading to the creation of my Tar module (based very heavily on Mauricio’s code, but also incorporating a number of changes); this will be released as a separate package with a limited tar/untar program at a later date. I now have the ability to pull Ruwiki data, templates, and executables from a central location. Because the feature was so easy to add, I have made it possible for users to package their wiki (into a .pkg file) and unpackage it elsewhere. I am completing the deployment command-line now. It used to be that one would do:
% tar xvfz ruwiki-0.8.0.tar.gz % cd ruwiki-0.8.0 % ruwiki_servlet
Now, one will do:
% gem install ruwiki % ruwiki install --to ruwiki # installs the data/ and templates/ to ruwiki/ % cd ruwiki % ruwiki_servlet # pulls from the stub installed by RubyGems
The third and final step for this is packaging. My packaging requirements have become far more complex, so I have to automate the packaging process. When I release Ruwiki, now, I will need to check out the codebase, create a default configuration file (ruwiki_servlet --save-config) for the current release, create the default deployment package for the current release, build the gem with those files, and then create the .tar.gz distribution. I also need to PGP/GPG sign the released files.
Those who have looked at my releases will have noted that I touch all of my released files to the date and time of the release; this will actually be easier to deal with using an automated packaging process, but this is part of the process.
1 Yes, you could copy the executable files (ruwiki.cgi or ruwiki_servlet) and modify those before running, but this is less than ideal for many things.
2 I didn’t use YAML because of various problems with YAML across versions of Ruby, including parts which still do not work with Ruby 1.8.2 preview2 on Windows–and I am not in a position to test post-preview2 code at the moment. I didn’t use XML because that would add another dependency to Ruwiki. Finally, I didn’t use Marshal because I wanted the files to be human editable.
