Update: Sylvain has just posted a FANTASTIC overview of LLUP, looking at things from the view point of the importance of its transport protocol independence, and some of the problems we have specifically set-out to help solve in regards to reducing the use of network resources, allowing for those same resources to process more information, in less time. I would encourage you to stop by for a visit just as soon as you have a chance.
Just got a ping from Russ regarding an article he just finished up that implements an LLUP subscription web service that communicates between Ruby on Rails and the .NET platform via a SOAP-based Blip Messaging service,
This article, the first in a series of three from Russ Miles, will cover how to get started with a simple web service in Rails. We’re going to create a web service and then test for interoperability with a simple C# application.
some most might be asking,
in which I would respond,
Excellent question… Thanks for asking. :)
[From the above linked post from Russ]
… The LLUP System in a nutshell
LLUP stands for Limited Lifetime Ubiquitous Protocol. What is does is simply allow you to subscribe to particular types of content (on criteria such as geographic area of interest or other simple keywords) and then for content producers to notify your account when something of interest has been made available. Think of it as a system somewhere between email (push) and web sites (pull). A content producer puts out some content and then sends a notification, called a blip, into the LLUP system. The LLUP system the smartly propagates the blip to anyone who has expressed an interest. A presentation overview of the LLUP system is available here.
To do this, LLUP is made up of three services that are all defined using open standards. The Publication service provides an interface where content creators and producers can tell the system that new content is available and what it is relevant to (and also to ensure that only known sources can send into the LLUP system, overcoming some of the issues with spam*). The Subscription service allows content consumers to subscribe to different types of blip. The BlogXast service is a combination of a publication service and the subscription service in that it provides a smart router that can route blips intelligently throughout a system.
Although different implementations of the LLUP services are possible, web services are the most common and so that is what we have implemented with Rails here.
Okay, theres actually quite a bit more to LLUP and Blip messaging than this, and I’ve copied a few things over below…
But if I could suggest an order in which to “process” this information, it would be like so,
a) Russ, as usual, has created a fantastic “step-by-step” guide(same link from above) to developing your first RoR <> SOAP <> .NET-based LLUP subscription service. I would start here first.
b) Jason Kolb has recently written a FANTASTIC MashUp blog entry that explains in vivid detail how various pieces of the semantic web puzzle (e.g. LiveClipboard, LLUP, more…. ) can be pulled together into something that makes a TON of real world practical sense. I would visit Jason’s entry next.
c) Russ has several links already to the LLUP spec [credit: Sylvain Hellegouarch, who shares the role of spec editor, with Russ, for the development of the current specification that Russ links to] and overview so theres no need to link to it in this piece… you can just go there and get access to this information. If necessary, I would return to Russ’s post and visit these links.
d) And if you just HAVE to have more than this, I’ve copied over the relavent pieces of a recent overview of LLUP I sent to the LIVE-CLIP mailing list below.
If thats not enough, then I guess you’re just gunna’ need to wait until theres more to give, cuz’ at the moment…
There ain’t .
NOTE: Quick show of hands from those who just got the “spelling and grammar heebie-jeebies” from that last bit?
Wow! All of you?
Huh… That sucks.
Well, then I guess I will leave you in peace (for now ;)
Thanks for the demo/walkthrough/kick-butt intro into LLUP, Russ! :D
EXTENDED INFO BELOW
… Russ and Sylvain (cc’d) are jumping head first into
pushing out code samples and the ongoing development of the spec, and I
will be focusing more of my time on the GlobalClip project and a few other
projects that are related… see:
http://www.x2×2x.org/projects/wiki/doku.php for some of the related LLUP
content. But LLUP is and always has been my passion, and has been for some
time. The same can be said of both Russ (co-inventor, spec-editor),
Sylvain (spec-editor, significant contributor) , Kurt Cagle (significant
contributor to early design) , DonXML (significant contributor, owns the
categorization piece of the spec), to some extents Uche Ogbuji (helps keep
us all in check to make sure we don’t stray too far from course :), and a
few more folks that have plans to get involved at a later date…
So, I know you all can see the obvious connection, so yes, in fact LLUP is
just PULL spelled backwards, and furthermore is, quite simply, a crossover
of both push and pull styled messaging combined together to bring the best
of both user choice together with the more delivery styled approach that
email offers without any of the problems that comes along for the
free-ride as part of email (e.g. by default, anyone can send a Blip
message, so SPAM can continue to exist, but the choice is flip-flopped > I
have triggers set to snag all messages that promise me Male enhancement
that will… you know the rest < and as such, when a message hits the
system that matches this criteria, it sucks it down to my machine -- but
the message is only, in essence, the equivalent of an email header... the
message itself is stored in either the users publicly accessible web-share
folder or an or somewhere else that the user has access to both post the
message, as well as host the requests for that message (and if desired,
implement secure control of that content.)*
The point? Instead of 10 million spam messages, one message is sent to a
server that is willing to propogate such messages, but it points back to
the originating server to gain the actual content placing responsibility
of bandwidth on the sender of the message, instead of the free internet
lines at our cost instead of theirs = user choice and massive reductions
in bandwidth and overall cost.
One important note: LLUP implements start and expiration dates for the
related content e.g. If an event takes place tonight, you don't want it
returned in your search results tomorrow morning for "concerts in Seattle
this weekend" Nor do you want last weeks sale items from your local
grocery store as part of this weeks offerings only to find out when you
arrive its not on sale anymore, etc.... Of course this has to do with
LIVE-CLIP how? They go hand in hand, and in fact if you visit
http://extf.net you will discover an interface that looks a bit different
than the last time you visited. (unless you have visited in the last 12
hours, then no... its not any different The ability to copy and paste
meaningful content from one message to another is of obvious value in the
world of messaging... Some pics from your space on MSN Spaces into a
message that you want to send to your family... A list of contacts from a
group at work that relates to a particular project you are both working
on, etc... etc.. etc..
- One Part *Atom*
- One Part *Atom Publishing Protocol*
- One Part *An entry on your personal blog* 
- One Part *Web-based Delivery Transport* of some sort 
- One Part *Blip Messaging*
- and as many parts necessary, *SemanticWeb-enhanced Search Engine/Data Collection and Distribution Service* (e.g. Google, MSN/Windows Live, Yahoo!, A9, Technorati, PubSub, etc…)
Bake at 350 degrees for 14 minutes until just lightly golden brown.
Serve while hot!
Oh, and please share :D
 no more copying things into your sent folder, no more need to store copies of messages on an IMAP server, no more concerns with “data lockdown” (as long as you choose a blogging tool/service that gives you easy in/easy out access to your blog entries. Most do, some don’t), no more cluttered inbox from hell (the start/expiration dates clean out your inbox for you… its up to you if you choose to archive expired items, or delete them altogether, but your inbox in and of itself gains a built in “Garbage Collector” that remains fresh with only the messages that are currently in context with the chosen date range, category, and location filters.
 e.g. SOAP, SMTP/XMTP, XMPP/Jabber, WCF, REST-styled APP extension, some other protocol you prefer/invent thats better than these, etc…