This post originated from an RSS feed registered with Java Buzz by Brian McCallister. Original Post: Darn you, Leo =) Feed Title: Waste of Time Feed URL: http://kasparov.skife.org/blog/index.rss Feed Description: A simple waste of time and weblog experiment Latest Java Buzz Posts Latest Java Buzz Posts by Brian McCallister Latest Posts From Waste of Time

Leo Simons challenged me again =) Okay, thinking about it some. No code but...

You don't really need continuations for linear web programming. They are the best existing way of representing the idea though. You need something to track the state, and something to get compiled (or interpreted and have state stored) representing the state machine. Ruby doesn't have macros (tons of fun stories there) but method_missing, mixins, and singletons (not GoF singletons) allow for very similar domain specific structures.

The problem, I tend to think a little non-linearly, sorry for jumps, being addressed is linear programming for web apps in ruby. Rails rocks, but it is another action based system. Ruby supports first class continuations. They are, however, bound to the (ruby) thread from which they were generated. This is a bit tricky for web applications. I don't know for sure how Borges deals with it, but from playing with Borges... I am going to guess "not well" is the answer.

Okay, so we need to either use a single-thread model, be able to re-attach a request to the thread that the session is associated with... hmm, I wonder if continuations span fork in ruby, anyway... or fake out continuations by managing a seperate binding stack (convenient as, while the performance is less than ideal) you can treat a scope binding as a first class object in ruby.

More brain dumping, need some music... okay. So we need to simulate the behavior. It is acceptable to require explicit binding of state which traverses responses to something (we'll call this a wombat for lack of good name and not wanting to interrupt thoughts), that is reasonable. It beats state machines (wheee), even if it is a touch unnatural. So you have something like:

class BlogPoster < Wombat

  include RepositoryHelper

  def create_entry
    title, body = get_title_and_body until title and body
    
    category = case body
      when /[Jj]ava/, /argumentative/ then "java"
      when /[Gg]roovy/ then "groovy"
      when /[Rr]uby/ then "ruby"
      else "misc"
    end
      
    begin
      entry = repo.createEntry(category, title, body)
    rescue
      send_page "data_error"
    end
    
    send_page "home"   
  end

  # returns request params specified
  def get_title_and_body
    self.get_response("entry_input", [:title, :body])
  end

end

Hmm, looking at that and no go. Need to keep stack information, pointer to execution, etc. Continuation. Okay, so we know we need continuations, and we know continuations are bound to the ruby thread that spawned them. get_response specifically needs to do a callcc to something which will hold the continuation and come back on next call from client.

Okay, diving into Borges to see how they handle multithreading... argh am supposed to be hacking other things...