1. Sources of revenue.  I have five in mind.  None include banner advertising or sponsored sites.  I am going to work on firming these up and will keep them under wraps for competitive reasons. 
2. Expert weblogs.  The initial response has been great (my mailbox is full even though this is a holiday weekend).  I am working on a strategy for bootstrapping this into a structure (from both the readers and authors perspective) that provides value.  Great ideas on this front.  Will assemble a team to figure this out.
3. Infrastructure and hosting.  I am looking for ideas here.  The structure of the Weblog Network is fairly simple with relatively little centralized architecture.
4. Design and programming.  I have a preliminary conceptual design in place, however it is very rough and open to discussion.  Looking for help here of course.

If you are running a service aimed at webloggers and want to join in on this, let me know (BlogStreet, Daypop, Technorati, and others come to mind). [John Robb's Weblog]

7:55:47 PM     comment []     

In a single HTTP Request/Response transaction there are a total of six places that information can be stored. If you are designing a web service, which of the six you choose depends on the context, i.e. where and how your service is going to be used.

For an illustrative example, consider this elided request/response from the draft EchoAPI RFC. Here is the request:

POST /reilly HTTP/1.1 Content-Type: application/not-echo+xml <?xml version="1.0" encoding='iso-8859-1'?> <entry> <title>My First Entry</title> <subtitle>In which a newbie learns to blog...</subtitle> <summary>A very boring entry...</summary> ... </entry>

And the response is:

HTTP/1.1 201 Created Content-Type: application/not-echo+xml <?xml version="1.0" encoding='iso-8859-1'?> <entry> <title>My First Entry</title> <subtitle>In which a newbie learns to blog...</subtitle> <summary>A very boring entry...</summary> <link>http://example.org/reilly/2003/02/05#My_First_Entry<;/link> <id>urn:example.org:reilly:1</id> ... </entry>

The six different locations to store information are:

1. The request URI. Okay, this is the first line of the request and also contains the method, like GET or PUT, I'm lumping them together to simplify things.
2. The request headers, in RFC 822 format, you might remember that I've talked about RFC 822 Headers before.
3. The request message body.
4. The response status code. This is the first line of the
5. The response headers, again in RFC 822 format.
6. The response message body.

That's a lot of choices. When designing a service it's not always clear where some components of a message should be placed. For example, if you are attaching to a service that requires authentication, do you encode the authentication information into the requesting URI, do you use one of the HTTP authentication mechanisms which puts the authentication in the request headers, or do you put a name and password into the message body being sent? You could also send custom HTTP headers with authentication information. None of the choices are inherently better than another. All of the choices have their pros and cons, and each are appropriate depending on the context.

For example, Bulu, the code that runs this site, encodes the authentication information in the URI when doing Editable Comments. It's the least secure method, but the given the context, editing comments on a weblog, it's adequate. On the other hand, Bulu uses one of the HTTP Authentication mechanisms when creating or editing entries. That action requires more security than editing comments.

So where should you store your information? Beats me, but just keep in mind that as you design your service that you have six places to choose from.

7:51:05 PM     comment []