Windows Live Blog Posts (page 1 of 6)
I just uploaded a new version of my Pygments for WL Writer plugin to my skydrive. Nothing major here – some minor UI cleanup + an upgrade to IronPython 2.6 beta 2. Installing over the old version worked on my machine, but that’s as far as my testing has gone. I also pushed the latest source out to GitHub.
I’m still waiting on a fix for what Dino has taken to calling “Harry’s Pygments Import Bug” – which actually turned out to be three importer bugs. The Pygments lexers package is customized so as to abstract away the specific modules the individual lexers are defined in. I don’t use that functionality – I’m using get_all_lexers and get_lexer_by_name instead – but the bugs caused importing the package to fail so in the mean time I commented out the lines that don’t work under IronPython. I think Dino’s got the fixes for this checked in, but I probably won’t update Pygments for WL Writer again until IronPython 2.6 RC.
I just replaced the original v1.0.0 Pygments for WL Writer installer with a new and improved v1.0.1. The original URL still works – I archived the old version off with a new name. Updated source is available on on GitHub.
The only change is that I now override OnSelectedContentChanged in the sidebar control. That way, if I have multiple blocks of pygmented code in a given post, the sidebar UI updates with the correct language and color scheme of the currently selected code block.
For the past few years, I’ve used the CodeHTMLer plugin for Windows Live Writer for the code snippets in my blog. However, recently I discovered the Pygments Python syntax highlighter package which supports scores more languages than CodeHTMLer does. It also support multiple color schemes and was easily extensible so I could build an HTML formatter that didn’t use <pre> tags (which I’ve found DasBlog has issues with in the RSS feed, though honestly I’m running three minor releases behind the latest DasBlog release). IronPython supports Pygments just fine – at least, the one IPy bug that Pygments exposes has a simple workaround – so I set about building a Windows Live Writer plugin that uses it.
If you’re simply interested in the plugin itself, you can get it from my SkyDrive. The source is up on GitHub. For now, if you find any bugs, please leave a comment on this post. If there’s enough interest I’ll setup a site somewhere (CodePlex perhaps) where I can track bugs and feature requests.
Pygments for WL Writer is a smart content source. In WL Writer’s terminology, that means when you click inserted text in the editor window, it is treated as an atomic entity which you can then edit by using the Edit Code button in the Pygments for WL Writer sidebar editor. I I often found that I would edit my code multiple times – usually to shorten lines so they’d fit on my blog without wrapping. CodeHTMLer for WL Writer is a standard content source, so it just spews the formatted code as HTML onto the page.
From an IronPython perspective, there’s some interesting stuff there. I decided to compile the pygments library into a DLL for easier distribution. If you look in the source, there’s a folder for the Pygments source as well as the parts of the standard Python library that Pygments depends on and my custom HTML formatter. Those all get compiled via a custom script which can be called by the build.bat file in the project root.
Some features I’m thinking about adding:
- An extensibility model so that you can add new languages by dropping new Pygments lexers into the same folder the plugin is installed to. Pygments supports lots of languages, but not all of them – notably it’s missing Powershell and F#.
- Support for new HTML formatters and color schemes using the same extensibility mechanism described above.
- Support for selecting an HTML formatter.
- Improving the code editor window. Currently, I’m using a standard WinForms multi-line TextBox, but that leaves a lot to be desired. With the Python work I do, I often need to be able to select a bunch of text and change it’s indenting via tab and shift-tab. If anyone has a suggestion for a good WinForms text editing control, let me know.
- Being able to specify the font and size of the Pygmented code.
- Storing user preferences – remembering the most recent syntax and color scheme the user used.
Feedback, as always is appreciated. I’ll probably write a few posts about the project when I get a chance, so let me know if there’s anything you’re dying to hear about.
One of the cool things about the Live Framework is that while there’s a convenient .NET library available, you can use the raw HTTP interface from any platform. LiveFX data is served up over HTTP and is available in ATOM, RSS, JSON or POX formats. As I’ve already shown, you can easily use the .NET library from IronPython, but I wanted to try working with the raw HTTP interface to get a feel for that as well.
Unfortunately, it was harder than I expected it to be. The big issue is that the documentation on how to LiveFX authorization tokens via raw HTTP is fairly sparse and occasionally contradictory. For example, there’s a whole section on Authentication and Live Framework, but it doesn’t cover this scenario. Luckily, I was able to figure it out with the help of AtomPub Project Manager LiveFX Sample, a post on Alex Feinman’s blog, a post on Emmanuel Mesas’ blog and a little groveling around with Reflector. It does appear that the auth docs are in flux –Emmanuel refers to this MSDN article as being about RPS Soap requests, but it’s actually about delegated authority. (Is MSDN reusing URLs? Bad idea.) Also, the sample code has a comment that reads “to be replaced by delegated authorization” so it looks like changes are coming. In other words, no promises on how long this code will work!
If you look at the AtomPub Project Manager sample, there’s a WindowsLiveIdentity.cs file that implements static GetTicket method that looks similar to both the code on Alex’s blog as well as the implementation of GetWindowsLiveAuthenticationToken. The upshot is that there’s a WS-Trust endpoint for Windows Live at https://dev.login.live.com/wstlogin.srf. You send it a RequestSecurityToken (aka RST) message (with a couple of extra WL specific extensions) and it responds with the security token you’ll need for accessing the LiveFx HTTP endpoints.
I ported the GetTicket function over to IronPython. I’m using .NET classes like WebRequest and XmlReader, but there’s nothing fancy here so I would expect it to be easy enough to port over to the standard Python library.
def get_WL_ticket(username, password, compactTicket): req = WebRequest.Create(_LoginEndPoint) req.Method = "POST" req.ContentType = "application/soap+xml; charset=UTF-8" req.Timeout = 30 * 10000 rst = get_RST_message(username, password, compactTicket) rstbytes = Encoding.UTF8.GetBytes(rst) with req.GetRequestStream() as reqstm: reqstm.Write(rstbytes, 0, rstbytes.Length) with req.GetResponse() as resp: with resp.GetResponseStream() as respstm: with XmlReader.Create(respstm) as reader: if compactTicket: name = "BinarySecurityToken" namespace = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" else: name = "RequestedSecurityToken" namespace = "http://schemas.xmlsoap.org/ws/2005/02/trust" if not reader.ReadToDescendant(name, namespace): raise "couldn't find security token element" reader.ReadStartElement(name, namespace) token = reader.ReadContentAsString() reader.ReadEndElement() return Convert.ToBase64String(Encoding.UTF8.GetBytes(token))
This code simply uses a WebRequest object to post the RST message to the WS-Trust enpoint then parses the result to find the token. get_RST_message uses standard Python string formatting to generate the RST message that gets posted to the WS-Trust endpoint. I’m not exactly sure why you need to convert the token value to a byte array and then Base64 encode it, but that’s what the sample code does so I did it to.
Once you have the authentication ticket, you need to download root service endpoint document in order to get the base URL and the profiles link. Then you can download all the profiles or you can download a specific one if you know it’s leet-speak identifier. LiveFX data can be downloaded in a variety of formats: ATOM, JSON, RSS or POX. You choose your format by setting the Accept and Content-Type headers.
I wrote the following functions, the generic boilerplate download function as well a specific versions for downloading JSON and POX:
def download(url, contentType, authToken): req = WebRequest.Create(url) req.Accept = contentType req.ContentType = contentType req.Headers.Add(HttpRequestHeader.Authorization, authToken) return req.GetResponse() def download_json(url, authToken): resp = download(url, 'application/json', authToken) with StreamReader(resp.GetResponseStream()) as reader: data = reader.ReadToEnd() return eval(data) def download_pox(url, authToken): resp = download(url, 'text/xml', authToken) return XmlReader.Create(resp.GetResponseStream())
Here’s some code that uses the get_WL_ticket and download_json functions above to retrieve the the user’s Personal Status Message
#Get user's WL ticket uid = raw_input("enter WL ID: ") pwd = raw_input("enter password: ") authToken = livefx_http.get_WL_ticket(uid, pwd, True) #download root service document service = livefx_http.download_json(_LiveFxUri, authToken) #download general profile document url = service['BaseUri'] + service['ProfilesLink'] + "/G3N3RaL" genprofile = livefx_http.download_json(url, authToken) print genprofile['ProfileBase']['PersonalStatusMessage']
POX is also fairly easy, though a bit more verbose than JSON. The sample code, which I have stuck on my SkyDrive, includes both POX and JSON code, so you can compare and contrast the differences.
Ori Amiga is a Group Program Manager over in the Live Framework team whom you might have seen at PDC08 delivering the Lap Around LiveFX & Mesh Services and LiveFX Programming Model Architecture and Insights talks. And apparently, he’s an IronPython fan as posted a small LiveFX Python module to his blog. It’s pretty simple – it only wraps Connect and ConnectLocal – but it does cut about ten lines of path appending, reference adding and module importing code into a single import statement. Here’s the profile access script from my last post rewritten to use Ori’s LiveOE module.
import LiveOE from devhawk import linq uid = raw_input("Enter Windows Live ID: ") pwd = raw_input("Enter Password: ") loe = LiveOE.Connect(uid, pwd) general = linq.Single(loe.Profiles.Entries, lambda e: e.Resource.Type == LiveOE.ProfileResource.ProfileType.General) print loe.Mesh.ProvisionedUser.Name print loe.Mesh.ProvisionedUser.Email print general.Resource.ProfileInfo.PersonalStatusMessage print linq.Count(loe.Contacts.Entries)
FYI, make sure you update the sdkLibsPath in LiveOE.py – I’m not sure where Ori has installed the LiveFX SDK, but it’s *not* in the location suggested by the read me file.
BTW, it turns out the WL Profile information is read only which answers a question I had. However, reading the thread it sounds like they will eventually get around to making it read-write at some point.