Sexp of DSL

dsl_sexp.rb

# Given the asynchronous nature of all operations, 
# a simple property assignment is actually a chain of callbacks behind the scene.

# Take this not too simple example

g.applications[:name => 'app_foo'].target_ip = g[:name => 'node1'].interfaces[:name => 'wlan0'].ip

# If we think about xmpp communication, the work flow would be sth like this. (simplified pseudo code)

g[:name => 'node1'].request_interfaces[:name => 'wlan0'] do |i|
  i.request_ip do |ip|
    g.request_applications[:name => 'app_foo'] do |apps|
      apps.each do |app|
        app.configure_targe_ip ip
      end
    end
  end
end

# Very convoluted... if we parse the original line into sexp using ruby_parser.

[:attrasgn,
  [:call,
    [:call, [:call, nil, :g, [:arglist]], :applications, [:arglist]],
    :[],
    [:arglist, [:hash, [:lit, :name], [:str, "app_foo"]]]],
    :target_ip=,
    [:arglist,
      [:call,
        [:call,
          [:call,
            [:call,
              [:call, nil, :g, [:arglist]],
              :[],
              [:arglist, [:hash, [:lit, :name], [:str, "node1"]]]],
              :interfaces,
              [:arglist]],
              :[],
              [:arglist, [:hash, [:lit, :name], [:str, "wlan0"]]]],
              :ip,
              [:arglist]]]]

# Confusing enough, but it maps the actual workflow we need to implement.
#
# For example:
# :attrasgn is the top level, we could map that to the configure operation which should happen last.
#
# the tree of :call indeed represents the order of execution, so we regenerate a chain of callbacks based on this tree.