Monday, April 05, 2010

WebService API

Silverlight and Ruby on Rails

Technical Discovery is taking a lot longer than it's supposed to have.

I've had a fellow Ruby/Rails friend direct me in the right direction. I'm a bit disappointed that I just couldn't Google "Ruby Rails Web Service" and get an easy tutorial. I don't normally expect that with all languages and frameworks but the reason I expected it from R&R is because it's new (relatively) and web-based.

I followed one tutorial that used the actionwebservice libraries. It didn't work. Completely.

A friend of mine said that I can easily control and create a web service out of the box. Simply by working with the views. I don't know enough yet. I do realize that the fast and furious way of R&R won't work. I'll need to go through the fundamentals in order to get it to work.

There is one issue though. This is going to be really interesting to me. From what I can tell, there is no support for generating WSDLs. Apparently, they don't believe in the bloat. This is a bit confusing to me because the WSDL is intended to just expose the information that your web service provides. Maybe it gets hairier than that, I don't know. All I know is that it does most of what I want. Easy database retrievals and JSON.

So why the WSDL?

.NET proxies that call web services are generated from WSDLs.

Now, I have to decide on whether I want to generate a WSDL (or write it manually). OR
I can just write my own transport layer for making these method calls. All of these calls would have to be asynchronous though. I would also need to serialize each of the responses into accompanying objects. That means I'll have to always update the client anytime I update the server. It's not that bad. I've done this type of thing before. I'll just need to do it on a background thread using the HTTPRequest and HTTPResponse objects.

There's nothing particular interesting about writing a WSDL generator. Besides learning about the WSDL spec and the Ruby syntax. Writing a transport layer maybe a decent exercise. I could always write it and compare my implementation with what gets generated by the proxy class.

Writing a WSDL manually would be the best and fastest option though. I could technically write the classes and method signatures in .NET generate the WSDL and then use it for Ruby. As sad as that sounds.

I'm going to go with the transport layer, I think. I think that it'd be an interesting exercise.

I've sat down with Q and gotten the rules of Sichuan Mahjong down. Fairly interesting. Oh yes, I have the codename of my project. I named my Bomberman project: code name Oklahoma. I'll let that sink in. This one I'm going to name it Project Hot Pot.

Here's the service API so far:

Lobby:
- Game[] DisplayGames
- gKey CreateGame
- pKey JoinGame (gKey)
- void LeaveGame (gKey)
- GameDetail DisplayGame (gKey)
- void StartGame (gKey)

Note: Designing a chatroom sucks using polling

Chat:
- string Say (gKey, pKey, message)
- string Get (gKey, message, timestamp)

Game
- GameDetail (gKey) -- overlaps DisplayGame (gKey)

Action
- Tiles GetTiles (gKey, pKey)
- GameState GetState (gKey, pKey)
- Tile GetTile (gKey, pKey)
- GameState Mahjong (gKey, pKey)
- GameState Pong (gKey, pKey)
- GameState Kong (gKey, pKey)
- GameState Sheung (gKey, pKey)

I haven't decided what goes in my objects yet. This is going to be the basic foundation of what I need. I'm going a little bit with and against the grain for this. In that I won't be using RESTful APIs properly. I'll maintaining only a little bit of state on the client-side. The rest will be done on the server-side (stupid I know ... but what can I do). This game can actually be played by entering the URLs inside a web browser. I don't think anything requires POSTs yet only GETs. Since I'm just going to be using polling for this ... I'll need to set timeouts for a game. Game state will also be stored on a database. What sucks is that the tiles need to be shuffled and stored into the database. It'll be base 84 ... maybe a CHAR(84) for the storage of the shuffled set? I don't know. I'll think about the server layer later.

I'll need another day to think about this. I'll need to draw what each client sees and the controls. Play a game in my mind of what they require and then do it again.

After that, I'll design the web-service. Since I'm doing this across two separate web applications … this should be interesting. I have no source control. I think I'll go with SVN onto an external drive. I could go with GitHub since it's just me. But I'll stick to what I can get. It's 4:17am now. I'm out.

Mac Hatred:
Apparently no Mac users enjoy reaching the beginning or end of a line using shortcuts properly. Also, iTunes copies any song I double click into its own directly. That bugs me. Then again, windows bugs me when it places hidden images into every directory when it downloads the album art.

No comments: