ongoing � Practical Transparency

Need For Speed � Even a nice clean well-known feed doesn’t quite solve the whole problem. Your typical feed-reader is set up to poll every half-hour or even less often, and there are those in the financial community who are not going to be happy with a potential half-hour’s latency in getting the news. �

I can think of one simple brute-force way to approach the problem, and another that’s a little more sophisticated. The simple solution is, assume that everyone who really cares will want to poll that material-news feed every few seconds. So, you stage Jonathan’s feed, not on the ordinary blogging infrastructure, but on a hyper-fast cache that can take that kind of transaction load; there might even be a business opportunity here for some infrastructure player to offer this kind of special-purpose staging.

If you want to get fancy, you could use something like the proposed new Atom-over-XMPP trick. The idea is that people who want ultra-low-latency feeds don’t poll, but set up a persistent connection to the provider’s server, which pushes entries down the wire the moment they become available. This is elegant in theory; in practice I’d bet on the brute-force polling approach, at least off the top.

And if you want it to really work well, take Atom, APP, XMPP, RFC 4661, OpenSearch, and LLUP (Blip Messaging) and thats it — Problem solved.

From my recent post to the LLUP mailing list,

http://www.rfc-editor.org/rfc/rfc4661.txt

The SIP event notification framework describes the usage of the
Session Initiation Protocol (SIP) for subscriptions and notifications
of changes to a state of a resource. The document does not describe
a mechanism whereby filtering of event notification information can
be achieved. Filtering is a mechanism for defining the preferred
notification information to be delivered and for specifying triggers
that cause that information to be delivered. In order to enable
this, a format is needed to enable the subscriber to describe the
state changes of a resource that cause notifications to be sent to it
and what those notifications are to contain. This document presents
a format in the form of an XML document.

Maybe its just me, but if you were to take (first and foremost),

The Content Creator

- Who would utilize the [Atom Publishing Protocol] for publishing the
content he/she has created.
- Which would then invoke a process in which generates/updates an [Atom]
feed providing subscription based access to this content.
- Which would then invoke a process which generates a [Blip Message] to
describe the time/date/contextual semantics contained in the content.
- Which would then be wrapped inside of an [Atom Notification] as the two
way PubSub delivery mechanism of these messages.
- Which would then be indexed by an indexing provider of some sort,
- Who would then make this content available via an [OpenSearch] machine
readable interface, proving a simplified, human understandable mechanism to
query this index for items of interest.
- Who might then use [RFC 4661 : Event Notification Filtering] such that
once they find that in which they have interest in they are then enabled to
set triggers in which to be notified when a match is made.

Wouldn’t that for all intents and purposes complete the circle of the
semantic webs life?

I mean, one might suggest that its the query mechanism in and of itself that
provides the real power, but I just don’t foresee Grandma Joe and Uncle John
punching SPARQL queries into their favorite search engine, scheming up ways
in which they can “Goose the System” to squeeze out “Every last drop of
RDF-Tripled juice this baby is capable of producing!”

Then again, maybe they will…

… Or maybe they won’t.

Call me cautious, but maybe its not so much about squeezing the RDF-Triples
to within an inch of ther well-formed semantically-enhanced result sets and
instead using a simple, standard, semantically enabled interface such as
OpenSearch as a machine readable format that provides simplified access into
much more complex systems in which, for all we know will automagically
generate the SPARQL or whatever else might be powering the semantic backbone
of our webified future, providing all the juice and then some that anyone
could, or even should be legally enabled to consume in any one (or even
two!) given sitting(s).

So what about SmallTalk/Squeak?

via http://groups.google.com/group/llup/browse_thread/thread/e67265432924df20

[NOTE: The uncompressed size of the entire set of Vista SmallTalk components
is less than 900k, though the core runtime and directly related libraries
are less than 100k total. One of the components made available as part of
the extended library is the JabberNet component. Though as outline below,
there are currently security restrictions that keep the JabberConnect
component from working within the context of IE7, it seems this will
(hopefully) be changing, and therefore become a viable option in regards to
the usage of an advanced messaging-based language such as SmallTalk (and
SmallTalk/Squeak are SO PHREAKING SIMPLE to learn!) coupled with the
advanced messaging capabilities of Jabber/XMPP.

When you consider the following two posts, the second of which showcases the
fact that the reality that this will become a cross-browser/cross-platform
solution, I’m sure you can fill in the blanks in regards to how Vista
SmallTalk could become a key component of an advanced messaging system [as
outlined in my previous post] in which could easily and efficiently provide
all of the missing features and capabilities currently lacking and
restrictions currently in place from the standpoint of internal browser
scripting languages and components such as XmlHttpRequest. In short, this
could very easily become the foundation of an AJAXian-esque future for both
browser-based as well as typical desktop applications.

Definitely something worth considering… [You can access more information,
as well as daily snapshots via the VST wiki @
http://vistascript.net/vistascript/docuwiki/doku.php]

[post:
http://vistasmalltalk.wordpress.com/2006/09/28/browser-instant-messag…]

I recently discoverd that the “JabberConnect” class doesn’t work from

- Hide quoted text -
> browser applications.

> The reason for this is the presence of a few lines of “unsafe” code in one
> of the support libraries. In .Net IL (the bytecode format generated bt C#)
> any use of memory pointers is flagged as “unsafe”, and the presence of even
> one “unsafe” statement flags the entire assembly as requiring “full trust”
> security.

> So while “JabberConnect” works fine in a desktop application (which is
> “full trust”), the same application will cause a security exception in a
> browser (which is “partial trust”).

> The solution is to rewrite the Jabber libraries so that they no longer
> require the “unsafe” code.

> “Frictionless deployment” = no friction for the user, lots of friction for
> the developer.

[post:
http://vistasmalltalk.wordpress.com/2006/09/19/projections-for-window…
]

Paul Thurott
recently

- Hide quoted text -
> posted this.

> “In an open letter to developers, Microsoft co-president Jim Allchin
> predicted that there would be over 200 million people using Windows Vista
> within 2 years of its January 2007 launch. This, he says, is an opportunity
> that hasn’t arisen since Windows 95, which was released over 11 years ago.”

> Internet Explorer 7 is the standard Web browser for Windows Vista, so this
> means 200 million installation of IE7 as well.

> Plus the automated IE7 browser upgrades on Windows XP starting in December
> (there are perhaps 500 million desktops currently running XP).

> Plus the number of WPF/E installations for Firefox, Safari and Opera
> browsers - both Windows and Macinstosh.

> Plus the number of “devices” (cellphones, PDA’s, consoles) that will
> use WPF/E.

> In short, over the next two years, there are going to be hundreds of
> millions of desktops/browsers/devices able to run Vista Smalltalk.

> A major technology change happening in a very short timespan - it should
> be interesting.

Don’t think all of this has been thought through, tested, and re-tested well enough to ensure any sort of reassurance that it will not only work — but work REALLY, REALLY well?

via http://www.jasonkolb.com/weblog/2006/07/the_technology_.html

Real bonafide Push, on the other hand, actively goes out and tries to deliver something to a user, and it’s on the verge of a comeback. This time what we’ll be pushing isn’t content itself, but update notifications and pointers to the actual content. As it always is, the best solution is a combination/compromise of two ideas–PUSH the notification telling somebody that there’s new content, but let them decide if they want to go PULL it to pick it up. The bandwidth problems that killed Pointcast would not have been an issue if they would have used the technology to push notifications instead of actual content. M. David Peterson, Russ Miles, and several others have done a great job creating a specification called LLUP (PULL spelled backwards) around these principles.

Don’t worry… It has. More than anyone could possibly imagine, or are even willing to provide notice/credit for.