RE: Abstracting the transport

[Peter Rodgers <pjr@xxxxxxxx>]

On Sat, 2004-02-07 at 22:26, Danny Ayers wrote:
> bob:
> > 	However, I think you'll find that the priorities of the
> > community are currently on defining the REST interfaces for Atom, etc.
> > since those will be the most commonly used for quite some time.
> 
> Yep, I think this is pretty likely to be the case.

I fully understand the reasons why REST on HTTP is the dominant channel
- this is perfectly reasonable not least because we all have far more
experience of this than cellphone text message gateways.

[I sound obsessed about text messages! It's just that my feeling is that
more people Text (in Europe at least) than Blog.  Providing the ability
to use Atom to enable Text message generated Blogs would be a massive
application sector.  The cellphone infrastructure also offers a very
nice credentialing mechanism and of course micro-billing.

On a broader point (and here I'll grossly over generalize) it's easy to
see blogging from the current perspective - essentially a one to many
publishing medium. Most valuable to special interest groups.  A blogging
protocol should also think about small closed group publishing (eg SMS
publish, SMS group notify/distribute, Web-archive) - a model that an SMS
channel definition may even drive. Enough on SMS!!!]

> There is more to abstracting the transport than taking XML and pumping it
> down a different pipe, but as far as the Atom format is concerned that's
> always an option. For the near future I think we're looking at per-case
> solutions for the API as/if they're needed, one for Jabber, one for email
> etc.

> Certainly security issues are a biggy, but I note in the OSI layers,
> authentication and privacy are right up in the application layer (I've a
> feeling that isn't quite what you meant).

I offered the OSI 7-layer diagram not as a literal map to follow. 
Rather it's an illustration of why layering in communications protocols
is essential.  In the OSI world Atom sits in the very top application
layer. What would an Atom layer model look like?  Without any deep
thought here's a suggestion

1) Blog Application
----------------
2) Generic XML Services: Publish, Subscribe, Syndicate...
----------------
3) Channel Specific Interfaces
----------------
4) Access Control
----------------
5) Channels

Applied to REST/HTTP this might be

1) Blog App
---------------
2) Generic XML Services: Publish, Subscribe, Syndicate...
----------------
3) URL Addressed Services: blog/publish , /blog/subscribe,
blog/syndicate...
---------------
4) .htaccess
---------------
5) HTTP

Applied to SMS this might be

1) Blog App
---------------
2) Generic XML Services: Publish, Subscribe, Syndicate...
----------------
3) Telephone Number Addressed Services: 08989 123-001 (publish) , 08989
123-002 (subscribe)
---------------
4) A-number authentication
---------------
5) SMS Gateway

The point is that everything from layer 3-down is channel specific - who
cares how it's done, if you want it go sort it.  Everything from layer-3
upwards is standard Atom XML messages.

Security is pretty much a channel issue.  The only requirement for Atom
is to define a standard XML structure to hold user identity and pass
this up from layer 3/4 to layer 2.

> It's pretty clear there won't be too much look-ahead in the development of
> Atom, the YAGNI principle is pretty strong around this community, even if it
> is (arguably) inappropriate for spec development. The immediacy of 'bits of
> the wire' syntax appears to have a hypnotic effect. Fortunately XML done
> well should be enough to make the simple things simple and the interesting
> things just a little more time consuming (two acronyms: XSLT, RDF). But
> getting back to your basic suggestion, (and being a little cynical) I think
> it unlikely that there'll be any abstraction of the transport layer when
> there isn't even the expectation of well-formed XML.

I'm a realist and understand this - it is certainly an effective way of
getting stuff done.  However maybe by interjecting this will spark some
ideas.


Pete