February 6, 2013
If you need to resolve DTDs locally with the
scala.xmlparser, you should provide a
This works out because
org.xml.sax.helpers.DefaultHandler, and this gives you the default no-op implementations of
I figured this out from related questions and answers on Stackoverflow.
October 5, 2012
We've published a Lift module to allow you to talk to Amazon SNS. SNS is Amazon's pub/sub system, and the module lets you register a function to receive messages from an SNS topic, and send messages to SNS.
The module just gives you the plumbing to send and receive messages, the config is in the project's README.
Here's the kind of thing we use it for:
This is all pretty similar to Diego's approach to a distributed Lift Comet Chat Application.
We don't actually use it for chat, but multi-user chat in Lift is an easy example to discuss.
Wiring SNS into a comet application
Lift handles the comet plumbing for us, and all we need to do is send a message to an Actor for all of that to be taken care of. But as the slides above indicate, we need to jump in an have those messages go out to SNS. This is how we do that.
LiftActorwith a new method which we call
When we say
ChatServer >! Chat("hi")you can see that if SNS is defined, we send the message to the SNS service; otherwise we deliver it as if the call had been made with
The implicit argument in that code means, whenever we call
>! Chat, we're making the compiler find the class that can serialise that
Chat. Consequently, we can't accidentally send to SNS something we don't know how to serialise, because if we tried that, the code wouldn't compile.
We do this for a bunch of reasons, one of which control over what is sent, but another is to avoid the message (
Chat) having to know anything about the serialisation mechanism. It's nothing to do with that class, and we might change out to a different pub/sub backend, and the
Chatclass shouldn't care at all.
Here's how it applies to us:
We're serialising as JSON, and for Chat there's really not a lot to pass other than the text of the message. Telling the compile the
ChatFormatobject is implicit means it can be used to satisfy the
SNSSerializerrequirement on our
The final part is handling the message back from SNS:
That's the function we register with SNS during
Boot. It's a bit annoying that the handler duplicates the actor call in your Lift App (the
ChatServer ! Chat(msg)part), but otherwise it all works out OK.
Hope that's of some use if you're running with N > 1 servers.
July 23, 2012
Don't commit time and effort to a service you care about if it doesn't give you the ability to get your data out. A promise of an export feature isn't an export feature.
Posterous has been my learning experience on that front. Despite saying there would be instructions for exporting "over the coming weeks", it hasn't appeared, and meanwhile I've watched the service rot.
Escape from Posterous
I ended up paying a few dollars to Export My Posts (which got most of my posts), then scripted the oh-so-handy Pandoc to do the grunt work of a HTML to Markdown conversion. Followed by hours of clean up by hand. But I'm in a happier place, and using telegr.am for this site. The data can be in GitHub or Dropbox, in the format I write it in, and the rendering is all hosted: perfect.
Update: Scrub all of that stuff about export because telegr.am natively imports from Posterous now.
Escape from Flickr
Flickr is wonderful, unless you have comments and have annotated images: that stuff can't be exported. So I've abandoned Flickr for OpenPhoto, which, although not as polished or feature-rich as Flickr (!) it has been created as "a cloud based open source photo sharing service where you own and control the photos, tags and comments". Since being kickstarted it has recently added Flickr import.
What about Twitter?
Mitigation. I use ThinkUp to record all my Twitter interactions.