On Naming Conventions and On Statelessness

I posted these to the mod-pubsub.org blog, but here they are for the mailing list to enjoy too...

  -- Adam



Naming Conventions, Part 2
--------------------------

In response to a recent discussion between Joyce and Randog on Mod-pubsub's naming conventions...

We have no naming conventions for Mod-pubsub topics -- they are as chaotic (and therefore as flexible) as a filesystem exposed via the Web. Use whatever conventions you use there. In general, the PubSub Server works equally well with any number of topics. (Ultimately, a topic's meaning is defined by its users.)

What happens if you have lots of messages floating around in an enterprise and each user only wants to get a subset of those messages? Depends on the application, but in general I find it easiest to have different topics for each combination of user and application. And/or different PubSub Servers for each user, with PubSub Clients to bridge them by subscribing to one topic and publishing to other topics (perhaps on other servers).

Regarding a filter API, we call that a program (written in Python, Perl, Java... whatever you like) that subscribes to a topic on one PubSub Server and publishes a (filtered, transformed, etc) subset of the event stream it receives to another topic (either on that server or on another one).

Note that, in addition, the PubSub Servers do support a subscription header kn_content_filter (whose value has Perl regular expression syntax), that passes to subscribers only events whose payloads match a particular pattern. See the PubSub Protocol document for more on this. 


Statelessness, Part 2
---------------------

I've been thinking about Joyce's post on the Web's benefits of statelessness. What do we mean by "statelessness"? After all, websites change all the time, app servers share session information, etc.

As we see it, the main benefits of the Web's "statelessness" are cacheability and load balancing of requests. Cacheability says that once you've fetched a particular resource, you don't have to re-fetch it until it becomes "stale", and there are criteria in HTTP for what staleness means. Mod-pubsub follows that model, and extends it so that there's a standard protocol for publishers to recommend an automatic expiration date for a resource, and to allow for earlier replacement in the form of resource updates. (Updates, of course, have the same issues as the existing Web's resource updates do.)

Mod-pubsub is stateless in the sense that all information flows follow the Web's caching model. Server-side we have a modified Web Server that "caches" information available to clients when they first subscribe.

What Mod-pubsub does above and beyond HTTP are: 

1. Subscriptions to resources, so that when resources change, updates can propagate without polling, and 

2. A workaround to broken networks, so that updates can reach clients through long-lived responses. 

#1 (subscriptions) is state -- maintaining the subscription tables -- but this is not detrimental to cacheability or load balancing (essentially, new publications get replicated to a farm of PubSub Servers, so that subscriptions can be cached and load balanced accordingly, just as a bank of Web Servers or App Servers work). And, #2 (networking workaround) is not state, it's just HTTP push, but with useful information rather than fluffy media frames.


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01