[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Hello, and some API concerns about browsing/searching
> Good point. Obviously I am client-biased. But I think we can resolve
> some of this tension if we consider that the server actually consists
> of two parts: one is a faceless database of posts, the other is the
> template and CGI code that serves up HTML pages to web browsers. The
> latter is actually a client, a web application. Some of the areas where
> the server says it wants control are because of the HTML presentation
> that it's generating, not so much due to managing the post database.
>
> So: I think the core server's main job should be to act as a post
> database. Obviously that implies imposing some kind of schema on the
> organization of the posts. But beyond that, things the server wants
> tend to be because of its embedded web-app-client portion, and those
> need to be balanced against the needs of other types of clients.
The schema will presumably just describe a collection of well-formed blog
entries, and appropriate structures to return query results (search etc). I
wonder what form that schema will take, given that the plan is to support
extensions. Or maybe the syntax will save us.
> A useful thought experiment might be to ask whether the two halves of
> the server could be separated, connected only via Atom. That is: is it
> possible for a client of the Atom API to generate/serve the web pages
> that make up the browser's view of the weblog/wiki/whatever?
I think this is worth considering as more than a thought experiment - loose
coupling at that stage would make a great deal of sense, making such a
system considerably more versatile. Existing tools are fairly
straightjacketed into roles thanks to the nature of the comms - Blogger API
going one way, RSS the other. Viewing the blog servers, clients and
aggregators as being instances of agents that speak Atom loses the
straightjacket. An immediate use case would be a community blog, which could
not only have multiple client contributors but multiple servers too,
providing different support for different parts of the community.
btw, the spike [1] I did (Really Simple Blogging) with the API delivered
nothing but the Atom data to the browser. If were going to have full entry
content in the feed, it should certainly be possible to pass such material
straight to a browser (although usually you'd want something like XSLT to
extract the content first).
Cheers,
Danny.
[1] http://dannyayers.com/archives/001672.html