bopuc/weblog

off-topic: And I wonder what was REST about it?

Tumbleblog: People needs names to exist. So they create names and a way to exist for old practices is to mix "tools" and "modalities".

Yes tools might change modalities, but most of the time, tools just change the point of view on the exact same modality. And when I read "A tumblelog is a quick and dirty stream of consciousness", I quickly say to myself "Oh man, please cut the crap, tell me just what it is supposed to do."

* Is "Tumbleblog" the end product of "New Post Bookmarklet of MT"?
* Is it what I use to quote things on the Web in email?

That would be interesting to ask people to define what they think it is without talking about the tool to maintain it.

answer to first question: Bosko's system is engineered around REST and he decided to focus his presentation on that aspect largely.

as for the rest (hehe), yes. agreed. ;)

boris, you said a while back that part of the problem of weblog fatigue is that people want to start doing different sorts of things with their weblogs, and the tools aren't letting them do that easily (it can be done but you gotta build it yourself). i think part of this is a simple question of content categorization and display... that people want easy ways to display different types of posts differently. right now it takes some work.

Bosko's project, as I understand it, is to try to get a more "structured" feedback loop for "unstructured" content. ie find an easy way to for a group of like-minded tumblers to see and exchange their tumbles, repackage, reuse. I'm not totally sure what this adds to existing blogging methods, but the idea is interesting.

Currently I use delicious links tagged "sidebar" to do something like this - to display things of interest with a little comment, not worth a blog post ... but a better system could surely be built. My understanding is that bosko wants to include media in this, so that more than just text and links can be displayed .. and shared across a network.

I think.

Right except the problem has never really been "how to get the content in", it's "how do I display it" or "what do I do with it once I have it".

I looked at a dozen of the featured tumblelogs and each and every one was just a "river of news" style reverse chrono aggregtion display, with little differentiation between content. And little if no indication of context.

Again, not saying it's a bad idea, just that I had hoped someone was doing something really new, and not just applying a new brandname to something that really is an incremental point release. ;)

Or am I missing something? ;)

Also, until someone shows me a mobile device app that posts to these things, I'll keep my arms corssed across my chest smiling. Prick that I am.

You're not a prick, Boris. And I am really glad to see discussion around this. Unfortunately, it was difficult for to say everything I wanted to in fifteen minutes, since I initially planned a thirty minute talk that featured the full motivation and a well explained architecture, pointing out why I thought the architecture itself was important, and urging others to adopt The REST Way.

Coincidentally, Simon Law in his later talk regarding web services and the openness of web services, brought up what I thought was an important aspect of data openness: the ability for the end-user to modify _how_ and _what_ data he pulls out of a service. This was a large part of what I wanted to get to with my talk, pointing out that REST _was_ the way to get there, and that Rails was increasingly making it easier to get there with ActiveResource. Secretly, and perhaps grudgingly, I want web service developers to stop building Yet Another XML-RPC interface that I will never use and start exposing resources in REST-friendly fashion.

For the record, and strictly technically, I think that we all agree that a tumblelog is to the end user very much like a blog, but generally with much shorter entries. Each entry usually also has a type, so that particular style can be applied to particular type (for instance, in my experimental tumblelog, I have a "ruby code" entry type which, when displayed, has syntax highlighting applied to it).

But: the purpose of tumblelogging -- the reason I do it -- is to quickly highlight interesting things that I read, browse, or otherwise encounter, and that I find are compelling and tell a story about what I'm thinking. It is a form of communication only a little similar to that that I use in my blog, but much more "loosely flowing" and creative. I don't tell you "this is me walking from point A to point B." Instead, I show you a picture from my journey and let you infer the rest, if you want to.

I like to think of the difference between a tumblelog and a blog in terms of flow. For example, in hiphop, an MC puts together a rhyme and adopts a _flow_. The _flow_ changes the feel and perception of the rhyme on delivery. In that same way, the blog, and blogging tools as a result, adopt a flow conducive to well-thought-out, fleshed out writing. Tumblelogging is not long drawn and too fleshed out. It's quick and almost impulsive. So the tools need to make doing this simpler.

But ignoring the "how do I get the content in" issue altogether, and considering solely the "what do I do with it once I have it": the river-of-news style of display might very well be the display I've chosen for the now-almost-ready-I-swear tumbl.es, but it's certainly NOT the format I wanted to bind people into. In fact, the very purpose of decoupling the presentation from the data-input in commutivity and the "edge application" model I presented, was exactly to demonstrate that other folks could play and figure out neater ways to present data (and REST was a natural fit for this decoupling). That's a large part of what traditional scrapbooking is about, after all.

I'll write in more concrete terms in my own blog some time soon. I'll also continue to flesh out my repositories so that I can open them up with more confidence and so that this discussion can continue.

Hi Bosko, thanks for coming by.
My disappointment was purely that I let my expectations balloon when you said scrap-booking (again, I am thinking about truly customized media layouts per post, on the front end), and was only disappointed when it was just used as a eupemism for a form of light blogging some of you are calling tumbleblogging, which I assure you undertsand.

I drank the REST kool-aid when it came out, but I don't give it has high importance as you do. Similarily, Ruby may have some neat libraries to make REST easy for developpers but so does pretty much every other programming language. I'm agnostic to those two layers myself. Though I am glad you are pushing "good ideas".

I know moblogging and full-time virtual co-presence and peripheral consciousness quite well, building, doing and living it full-time for the last 4 years. So I undertsand all of what you said and say.

I don't even mind that folks want to give this form of CMS usage, and the behavior associated to it, a nifty name of it's own. And I'm always amused when someone tries to define blogging. :) I just hoped someone had figured out how to break out of the text document.

I was also disappointed that no one understood my question to Simon. REST + RDF is something you should be looking very closely at. ;)

(Flow: Public Enemy, Rialto, 1991. De La Soul with opening act DJ Jazzy Jeff and Fresh Prince, 1991, at the roller-rink which used to be where the Bibliotheque Nationale is now. ;)

When you say "truly customized media layouts per post, on the front end", what exactly do you mean? Can you describe with an example? I do have that concept in commutivity, and presumably you only really looked at Ozimodo, so maybe we're talking about the same thing but not connecting along the way.

As for your question to Simon I did understand it and I agreed with it, fundamentally. This is why I later pointed out to Simon that the problem he was highlighting was not in fact solvable by opening up source code, but by opening up resources and meta-data in discoverable fashion.

Hmmm I will have to explain what is REST and what is an information space. People are mixing many layers in the same cake. In the answers here, we see:

* Medias
* Communications
* Tools
* pseudo-REST
* HTTP
* Information space

to make it short, REST is not a GET with a nice URI, nor it is an API. Read that carefully

REST is an architectural style of interactions with an information space, relying on HTTP semantics.

I guess we will have to explain.

PS: Boris, official translator of Karl ;)

OOOOooooh and talking about UI and input modalities. Here Ijust wished to have a pen to draw things on my paper and that it would be posted as a comment right now. :)

Bingo. Sort of.
Say I wanted a "blog" (or call it what you want) in which I can pastiche stuff together, like in a scrap book. A web scrapbook. Thoughts, pictures, video clips, pulled together into the context of a "post".

Like opening up your Moleskine to *that* page where you sketched out your experinces of *that* day.

Just, not in a series of sequencial boxes; freeform layout.

WYSIWYG assembly of objects, published in web accessible format. I think perhaps some web-standards presentation layer stuffs are not yer ready/widely supported enough for massive deployement but surely someone could create a proof of concept XHTML 1.0 + CSS3 GUI editor...

hehehe. I totally understand that Boris. It is why since the start I'm making a point of separating the issues, to find the real solutions.

Why do you think it should be XHTML + CSS?
XHTML does one thing relatively in a good way is to describe *text* and CSS to style this text. Photos are not XHTML but most of the time JPEG. and other formats like PNG or GIF. There are SVG, SMIL and MathML and all of these are *just* formats and there are plenty of them with XML it is possible to combine them. If you look at Keynote (Apple slidemaker) for example, it is an XML format which is very similar to SVG.

Then as you said earlier I may need to explain the relationships between objects. hmmm wait this is here already. It is called RDF.

Then I need to modify, update, create and delete these bits of information (everyone here, notice that I didn't use the word file.) designated by an identifier (URI). Hmmm this exists, it is called HTTP.

So what is missing? ;)

What is missing is that people want absolutely to use a DUMB FUCKING TOOL to manage all of that: The browser!

The Web is a platform, the browser is one of the tool, not the only one. Every applications could communicate with a Web metaphor. There are starting examples of that. First generations of applications.

Ecto to edit a Weblog for example.
Songbird is another one based on XUL and Mozilla Engine. But still using the browser underneath.
Illustrator or OmniGraffle can save as SVG.

I think the main problem here is that people think browsers and then do not use the full potential of the Web being completely Ubiquitous.

The ironic thing is that, what we can call a scrapbook for the Web or at least its metaphor, was already created… 10 years ago in OpenDoc. If some people had the chance to use mac at this time, they will remember.

You could insert any kind of objects in any kind of applications. The metaphor was specifically the "scrapbook", in the sense you had a multiformat document which was modifiable by applications. The application was not the core, but the document was. Reversing the metaphor.

In the Web analogy, we call that a compound document.

Developers, please, think out of the browser! Think in terms of Web.

After reading where this conversation has turned to, I'm starting to think that there's some jumping-to-conclusions going around.

I want to ensure you, Karl, that I do know what REST is, and that the Commutivity model I talked about *is* REST. REST is *not* about just GETs on a URI, and I think I pointed that out in my talk. The entire application is designed with REST at its centre. In that, Commutivity exposes resources such as a "weblog", a "weblog post", and various other related resources such as collections of "weblog posts" and "tagged collections of weblog posts". It's not just a REST API that I'm talking about here, but the entire application is structured around performing GETs, POSTs, PUTs, and DELETEs on these resources (in fact, PUTs and DELETEs are "faked" because of the technical difficulties such as lack of browser support and web proxy brokeness). The REST APIness only comes into play in so far as some of the actions, in addition to returning just xhtml, also support the returning of other content types such as XML (in theory, I could also extend these to return any content type, like RDF, that could describe -- in RDF terms -- the relationship of said resource to others). So, it's not just about API, it's really about architecture, from the very top to the very bottom. Commutivity != Ozimodo.

Some examples:

GET /thinklogs returns a collection of your thinklogs (weblogs, tumblelogs, whatever you want to call them).

GET /thinklogs/1 returns a particular thinklog.

GET /thinklogs/1/thinklog_entries returns a collection of thinklog entries belonging to a particular thinklog.

DELETE /thinklogs/1/thinklog_entries/12 destroys a particular thinklog entry in a particular thinklog.

and so on.

All of the above actions return either xhtml, or xml, or both, depending on how and from where you query them (a web browser, another application, etc.) -- what I like about this, and what I was getting at in my talk, is that semantically, "API" and "UI" are pretty much equivalent, given that they both return different representations of the same thing.

Side: It just so happens that DELETE and PUT are often faked with a special parameter pushed through in the form of a POST, but that is only done by Rails so as to not break the current brokeness of web infrastructure. But this doesn't always have to be the case.

>Back to the question of Boris' WYSIWYG representation of resources at the edge application side: I think we really agree on what we want to achieve. I am of the opinion that the first step to getting there is to split the data-input from the data-presentation, and that is what I explained with Commutivity which is responsible for data-input, and various "edge applications" (such as tumbl.es) which are responsible for data presentation. Currently, I've only implemented the presentation of data in tumblelog-form, a form I was very familiar with and that served a personal creative interest. However, it's entirely possible to write an edge application which would pull the same resources and restructure their presentation in whichever way you saw fit. This doesn't have to be limited to the browser metaphor, either. It doesn't have to be just xhtml + css + js. It can be microformats. It can be RDF. It can be other XML. Really, the purpose of the split was exactly so that I can play around in the presentation layer without worrying about the data-input much.

Finally, it's worth noting that I opened up the tumbl.es source code, which is very small and simple enough to grok (http://saigon.tagsy.com/svn/commutivity_tumbles/trunk). If there is interest, when I'm done with Commutivity itself, I might very well open that up too, so that discussions such as these can continue through source code. :-)

Bosko: Many thanks for these informations. So now it's becoming clearer.

Bosko is interested by the layer of resources management.
Boris is interested by the layer of visualization of resources.
These two are completely different.

Bosko:"in fact, PUTs and DELETEs are "faked" because of the technical difficulties such as lack of browser support and web proxy brokeness)."

I'm trying to understand what you call a fake HTTP PUT.
What's happening if I use a client which does HTTP PUT?

karl: If you perform an HTTP request with REQUEST_METHOD == 'PUT' or 'DELETE' or 'POST' or 'GET', Rails will detect it as such, and will route accordingly. The "faking" of "PUT" and "DELETE" I am referring to is due to the fact that Rails will _also_ look for a special parameter called "_method" if the REQUEST_METHOD == 'POST', and if it finds it, it will use its contents as an indication to the actual request method instead of just assuming it is a regular POST. It does this simply because browsers don't send PUT and DELETE, and because even if they did, lots of proxies won't let them through. So:

GET is GET
POST is POST unless a _method parameter exists
POST with _method set to PUT is a PUT
POST with _method set to DELETE is a DELETE
PUT is PUT
DELETE is DELETE

Therefore, a real PUT or DELETE will work as expected.

In other words, a hack, on the backend (and if I undertsand correctly an HTML INPUT TYPE HIDDEN NAME = "_method" VALUE = "PUT/DELETE" , or a _method=put/delete in the GET) to route around poor/incomplete implementation of HTTP in browsers and proxies.

Not ideal, but understandably necessary, and apparently a Ruby-specific "solution".

Now, what was that Ruby killer porblem? UTF-8 support I believe? ;)
hehehe.

Karl: yes precisely. My interest is on the front end of all this.