blipflow?
Tim Lynch
Hey guys,
I've had a number of conversations with people recently about LLUP and BLIPs that seem to follow the same line of reasoning: "well, isn't RSS/Atom the same thing?" or, "I do that now with email!", etc., etc. In the latest such conversation, after a lot of hand waving and mad pencil sketching on my part, a light bulb finally went on for me: blips enable workflow.
From Sylvain's "Introducing LLUP" blog entry from ~month ago:
Feeds are great but not everything belongs to them. Say I have a regular HTML web page with one single image. I don't want to provide a full feed to inform users I have updated it. Instead I simply send a small blip when needed.
How 'bout if the current image object provided a way for me to register that I wanted to be blip'ed when Sylvain updated the image? What if every object on the page provided such functionality? What if the page itself provided a registration option: "I'll blip you when anything on this page changes"? The granularity of what I want to be notified about is left to me, the consumer. (Of course, the blog owner would set the initial, overall blip granularity and what per-object blip msgs he/she wanted to support.)
The ability to manage a set of keyword topic filters on some blogXast server is cool, but what could really set LLUP/BLIP apart is the ability to register on a per-object basis.
If registration-per-object is possible, then you've got a killer lightweight workflow tool that could be used for all sorts of things.
I'm imagining a smart-widget-w/tinyicon along the lines of Ray Ozzie's Live Clipboard where the tinyicon appears next to any object that wants to advertise it's blip-ability. Clicking the icon could provide a drop-down of available blip msgs ( [ 'Notify of any change', 'Notify of new content', 'Notify of new comments'] ). Obviously, not every object needs or wants to be blipable, but for those that do ...
ok, granted, there's some details to work out :) like, if a page-update blip goes out, how's it distinguished from an image-on-the-page-update? otherwise, what d'ya think?
Tim Lynch
Director, IT
231 Emerson Hall
College of Agriculture and Life Sciences
Cornell University
Ithaca, NY 14853
607.227.6498
tj...@cornell.edu
Sylvain Hellegouarch
>
> Hey guys,
>
> I've had a number of conversations with people recently about LLUP and
> BLIPs that seem to follow the same line of reasoning: "well, isn't
> RSS/Atom the same thing?" or, "I do that now with email!", etc.,
> etc. In the latest such conversation, after a lot of hand waving and
> mad pencil sketching on my part, a light bulb finally went on for me:
> blips enable workflow.
>
> >From Sylvain's "Introducing LLUP" blog entry from ~month ago:
>
> Feeds are great but not everything belongs to them. Say I have a
> regular HTML web page with one single image. I don't want to
> provide a full feed to inform users I have updated it. Instead I
> simply send a small blip when needed.
>
>
> How 'bout if the current /image object/ provided a way for me to
> register that I wanted to be blip'ed when Sylvain updated the image?
> What if every object on the page provided such functionality? What if
> the page itself provided a registration option: "I'll blip you when
> anything on this page changes"? The granularity of what I want to be
> notified about is left to me, the consumer. (Of course, the blog owner
> would set the initial, overall blip granularity and what per-object
> blip msgs he/she wanted to support.)
>
> The ability to manage a set of keyword topic filters on some blogXast
> server is cool, but what could really set LLUP/BLIP apart is the
> ability to register on a per-object basis.
>
> If registration-per-object is possible, then you've got a killer
> lightweight workflow tool that could be used for all sorts of things.
>
> I'm imagining a smart-widget-w/tinyicon along the lines of Ray Ozzie's
> Live Clipboard where the tinyicon appears next to any object that
> wants to advertise it's blip-ability. Clicking the icon could provide
> a drop-down of available blip msgs ( [ 'Notify of any change', 'Notify
> of new content', 'Notify of new comments'] ). Obviously, not every
> object needs or wants to be blipable, but for those that do ...
>
> ok, granted, there's some details to work out :) like, if a
> page-update blip goes out, how's it distinguished from an
> image-on-the-page-update? otherwise, what d'ya think?
>
Nothing to add. This was the idea behind my blog entry. Exactly as you
stated. This is in fact something that had striked me as well as one of
the greatest strength of a LLUP/BLIP system. Any resource should be
BLIPable (if I may abuse), or at least resources set as BLIPable (I must
stop that now) by the publisher should be.
The fantastic difference between this an email or syndication is, as you
say, the level of granularity as well as the flexibility of the LLUP
system. There is another big advantage to LLUP which can be described
quickly.
A few days ago I was googling (I should be careful as it seems Google
doesn't like using their name as a verb) for LLUP to see who was talking
about it. I found one entry of someone I don't think I had ever heard of
around the project [1]. Now imagine if this blogger had published his
entry to a LLUP publication service. Because I would be subscribed to
the LLUP service regarding LLUP, I would have received a notification
about his entry without having to search for it.
Of course because such capability could be abused as a SPAM, the LLUP
service could have removed it all together instead of pushing it to me.
Email can do this but well the mail protocol is so abuse with SPAM today
that I'm not sure this would be the best option. Syndication might be
able to reproduce the behavior to a certain extent (look at online
aggregators) but again cannot provide the different capabilities of a
LLUP service.
I can understand why people might get scared at yet a new protocol. we
have so many already. The interest aspect of LLUP however is that it is
independant from the underlying protocol that will carry BLIP messages.
Therefore it doesn't redefine the wheel. It simply polished it a little.
- Sylvain
[1] Link that I cannot find anymore of course...
M. David Peterson
In fact,
How 'bout if the current image object provided a way for me to register that I wanted to be blip'ed when Sylvain updated the image? What if every object on the page provided such functionality? What if the page itself provided a registration option: "I'll blip you when anything on this page changes"? The granularity of what I want to be notified about is left to me, the consumer. (Of course, the blog owner would set the initial, overall blip granularity and what per-object blip msgs he/she wanted to support.)
if you were to go through the archive of the original conversations that Russ and I had when we first began to nurture this idea, you would discover that this is in fact VERY similar to where we both could see this leading towards.
The primary difference between what you gain with Blip Messaging, and what you don't have with either web feeds or email is pretty straight forward,
- The ability to subscribe/unsubscribe to a person/place/thing (you get this with web feeds, but not with email.) This is the Pull side.
- The ability to send someone a message, without the need to subscribe to that message first (you get this with email, but not with web feeds.) This is the Push side.
Where they meet in the middle is where the distinct advantage come to be realized, and in fact, as you state, becomes part of a workflow system.
Take, for example, this VERY OLD mock-up of a work flow application:
http://dev.viberavetions.com/index.html
If you look in the upper right hand corner, you will notice several "Mode"s. The idea is simple,
By taking the two Push/Pull advantages from above, you gain granular level control over what messages gain access to your point of presence at any given time. So, for example, if I am currently working on some code, and to be interupted would mean losing my current "mind flow", I would set my current "Mode" to "Work". The definition file for "Work" might allow messages only from my team members that are of a certain subject matter that has to do with my current task (setting my current task via categories ( e.g. project name, particular task within the project)) through, and potentially "emergency only" messages from my wife (I'm not married, but thats obviously not important to this example :). Beyond this, however, the messages would be left in the queue for me to access when my Mode changes, or when I decide "Oh, I need to check on that while I'm thinking about it."
There are some other advantages as well.
- Because the messages are the equivalent of an email header, with the message content itself never leaving the original publish point, information that may never get read isn't be sent out across the wire. Theres also only one message ever sent out, of which is then propagated across the overall system (system: think of something similar to DNS with message queues) to each intended recipient whether that be a person, place, or thing. This places responsibity of bandwidth on the sender, instead of the free internet lines, enforcing a policy of responsibility which currently does not exist. The implications towards the effect on SPAM should be pretty obvious.
- By nature of the messages never leaving their publish point, conversations immediatelly become threaded by their very nature, eliminating excessive "re-sending" of the same data over, and over, and over again, something that I am sure you are aware can become pretty awful if a conversation go on for any length of time.
- Because of the required publish and expiration dates, your "inbox" gains an automatic garbage collecter, archiving expired messages or deleting them all together, based on user preferences, which can be, as you point out, granular down to every last detail of the message (sender, category, etc...)
- LLUP is build on a foundation of semantics, so dependent upon client software, your current message "view" is always contextual, enforcing, again, a simple system of work flow policy.
There are a few more, but this should give you the general pieces that should help others quickly come to understand the differences between web feeds and email.
Hope this helps!
/M:D
M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354
M. David Peterson
In the current Internet landscape, there might exist HUNDREDS of group lists, all centered around the same general topic. At present time, there is no way for me to subscribe to "Agriculture" and gain access to all of the various public conversations going on in regards to this topic. But what if I don't want something quite so general, and instead, only those conversations that have to do with "Agriculture" and "Outbreaks" (similar to your use-case)? And what if I only want those same messages that relate to the Central United States, and are contained within a certain date range (important for both an understanding of current outbreaks, but also useful from a historical snapshot perspective when doing research.)
This is the type of use-case where LLUP begins to shine. :D
M. David Peterson
http://netapps.muohio.edu/blogs/darcusb/darcusb/archives/2006/07/09/pyulike-vs-smartfox-centralized-vs-distributed#comment-816
In short, this is the same basic idea you are refering to, or Inter and IntraDocument communications.
NOTE: In my comment, I never explicitly make the connection between LLUP and AtomicTalk, but suffice it to say, this is where I have ALWAYS placed the focus of this project, although, and again, I've never publicly spoken of this project as its WAY TOO EARLY in its overall development to talk much about.
M. David Peterson
M. David Peterson
Uhh... I guess I do explicitly pull out LLUP -- Scratch that comment from the second to last post :)
Tim Lynch
thanks for the clarification guys.
so ... is my role in this project shaping up to be "if Tim understands what we're saying ..." :)
- Tim
M. David Peterson
Okay, still a few tears in my eyes, but they'll go away soon enough :) Regarding roles, much past the role of spec editors that Russ and Sylvain have attached to their names, I think we all kind of just throw things into the pot as they are needed, whatever that might be.
That said, everyone is going to be coming at this from a different perspective. The question of "why should I care?" has been brought up on more than one occassion, and to be honest, sometimes the answer is "you shouldn't." Of course, thats not to suggest that their point, whatever that may have been, has proven that LLUP isn't as valuable as we think it is, and instead that theres no such thing as a magic (or silver) bullet. On the flip side, sometimes the answer was "because of this, this, and this" and as soon as one of those "this"'s clicked on the light, they've never looked back since.
With all of this said, I think the most important thing that we ALL need to be looking out for is gaining a better understanding of what the needs are, and can LLUP be used to fill these needs.
Coming back to roles, I will be the first to admit that living inside of the "(white hat) hacker world" can most definitely distort ones view of reality, so if you are able to help keep us grounded as to the needs of the real world, then this would most certainly be a HUGE help!
Russell Miles
You received this message because you are subscribed to the Google Groups "llup" group.
To post to this group, send email to ll...@googlegroups.com
To unsubscribe from this group, send email to llup-uns...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/llup
-~----------~----~----~----~------~----~------~--~---
M. David Peterson
Amen to that!
>> although I'm not sure I count myself in quite that elite group it's a nice place to hang around
BAH! Your humility is inspiring, but... well... I'll just leave it at that ;) :D
I would most definitely second that Tim.
What we have here is a collection of some of the best developers in the biz (really; although I'm not sure I count myself in quite that elite group it's a nice place to hang around) and while we understand LLUP benefits from a technical perspective, and from our own domains, it's really fantastic to have someone on board from another domain that can give us questions such as "can it do this?", "what about this?", and not forgetting the incredibly important "but it doesn't appear to be able to handle this...".
All these questions are top notch, and of great help as we move ahead and shape LLUP in the future.
For my part, I'm usually coming at LLUP from a plumbing-type services place. While sitting in my hole and creating (or designing) those services that will make up a LLUP infrastructure (and like Sylvain says, this is more of a polishing exercise on existing standards which is a GREAT feature of LLUP) I am just as interested to know what the user-centric cases are that will exercise this infrastructure as if I was coding more user based stuff.
I guess what I'm saying, in possibly the most verbose way possible, is that your input is not just interesting Tim, it's crucial :)
Russ
On Tuesday, August 15, 2006, at 02:54AM, M. David Peterson < xmlh...@gmail.com> wrote:
>
><<Original Attached>>
Russ Miles
http://www.russmiles.com
http://www.UMLRanch.com
http://www.SOARanch.com
Russell Miles
M. David Peterson
>> watch this space!
Watching :D
humility = honesty, it's all the same to me mate.
Hoping to have more concrete LLUP services to get out there both source and as demo servers in the next week or so... watch this space!
Sylvain Hellegouarch
>>> watch this space!
>
> Watching :D
>
Getting some pop-corn. Mark please get some drinks will ya?
Russell Miles
M. David Peterson
M. David Peterson
M. David Peterson
M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354