Granted, Hecl’s demo application is not the sort of things end users are going to want to use on a day to day basis, but I thought I’d use it to go through the process and see what I could see about Ovi.

Unfortunately, it didn’t go well, I got this the other day:

Comments from the QA team:
FAILED due to the devices not compatible by OVI store, OVI supported devices are can be found from the link
https://publish.ovi.com/help/content_providers (public, Qa in progress -> Qa failed)

The file failed QA on the following target(s):

• Device: Unpublished Protos – XXXxYYY – Another Test Device

Which isn’t all that clear, putting it mildly. Hrm. Maybe I’ll try with something else just to see what can be seen.

I’ve been doing some work for a client, where we have to interact with a web service front end for Oracle (which also means that everything reflects Oracle’s “delightful” shortened table names, like UsrAddrsPhn…). I didn’t find a lot out there to do this in Ruby, except this helpful post:

http://willcannings.wordpress.com/2008/07/06/wsse-authentication-in-ruby-soap4r/

However, it wasn’t quite enough for what we’re doing, as we have to deal with a nonce parameter as well.

Here’s the snippet of code I created:

require 'rubygems'
gem 'soap4r'
require 'base64'

require 'soap/rpc/driver'
require 'soap/wsdlDriver'

wsdl_url = ARGV.shift
proxy    = SOAP::WSDLDriverFactory.new(wsdl_url).create_rpc_driver

# run ruby with -d to see SOAP wiredumps.
proxy.wiredump_dev = STDERR if $DEBUG

require 'soap/header/simplehandler'
require 'soap/element'
require 'xsd/datatypes'

class WsseAuthHeader < SOAP::Header::Handler
  NAMESPACE= 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'
  USERNAME  = 'Not really the username'
  PASSWORD  = 'Put your own password here'

  def initialize()
    super(XSD::QName.new(NAMESPACE, 'Security'))
  end

  def on_outbound
    security = SOAP::SOAPElement.new('wsse:Security')
    security.extraattr['xmlns:wsse'] =
      'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'
    unt = SOAP::SOAPElement.new('wsse:UsernameToken')
    unt.extraattr['xmlns:wsu'] =
      'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'
    un = SOAP::SOAPElement.new('wsse:Username', USERNAME)
    unt.add(un)
    pw = SOAP::SOAPElement.new('wsse:Password', PASSWORD)
    pw.extraattr['Type'] =
      'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText'
    unt.add(pw)
    # Create a nonce...
    nonce = SOAP::SOAPElement.new('wsse:Nonce', Base64.encode64((rand() * 1000000000).to_i.to_s))
    nonce.extraattr['EncodingType'] =
      'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary'
    unt.add(nonce)
    # The time format returned by XSDDateTime isn't quite right, so we
    # fiddle with it a bit.
    unt.add(SOAP::SOAPElement.new('wsu:Created',
                                  XSD::XSDDateTime.new(Time.now.utc - 30).to_s.gsub(/..*/, "") + "Z"))
    security.add(unt)
    return SOAP::SOAPHeaderItem.new(security, true)
  end
end

proxy.headerhandler << WsseAuthHeader.new()

... call proxy methods to interact with web service ...

The key thing is to dress up the outgoing header with all the right XML, including Nonce and Created parameters. This code was created by matching the XML generated by the Java code used to interact with this “JAX-WS” web service.

All in all, it’s a bit of a mess compared to a nice REST style web service. Hopefully the above code will be useful to others who are in a similar situation.

I’ve written several articles (*) lately that are, if not exactly critical of github, certainly question some of the community dynamics that have sprung up around it. I’m not the only one:

http://www.cubiclemuses.com/cm/articles/2009/04/28/a-community-of-rockstars/

However, I think the Github guys have actually done really great work, and done some cool stuff. And I think – and hope – that they’re here to stay, so instead of focusing on what’s not quite right about it, I thought I’d toss out some ideas on how it could be fixed. Some of them may not be great, but hey, that’s what you get for free – go ahead and throw out your own ideas too.

• When you clone a project, it’s techncially a “fork”, but it’s not necessarily a fork in the real open source sense of “ok, I think I’m better able to develop this code, so I’m going my own way”, ala xemacs or x.org, or the bsd’s splitting apart. It might be nice if github gave people the means to indicate what sort of fork they’re creating – if it’s just a place to play with and publish some code, or if they think their code should be the one others reference.
• Perhaps it should be optional to copy the wiki and issues tabs on your new fork. If you’re not really aiming to supplant the main project, do you really need those? You might need the issue tracker.
• It might be an interesting experiment to let people vote on which one is the main project. Forkers could also indicate which one they want to keep working with as the main branch and maintainer.
• Perhaps github could add some visual encouragement for people to send their patches on to the main branch of a given project.

Anyway, just a few ideas off the top of my head.

(*)
* https://journal.dedasys.com/2009/01/10/developer-project-or-project-developer-s
* https://journal.dedasys.com/2009/01/21/more-github
* https://journal.dedasys.com/2009/01/22/github-part-iii
* https://journal.dedasys.com/2009/04/29/will-the-real-exception_notification-please-stand-up