Camen Design Forum

ThinkTank

append delete Jonhoo

I figured I'd continue the discussion from GitHub (github.com/…) as suggested.

> You should perhaps take this discussion to the forum rather than the bug tracker. :)
Consider it done.

>> Will Atom be supported as well, or will ThinkTank be RSS only?
> I don’t even know what the difference is. Does it even matter? ThinkTank will use whatever is necessary to implement it.
> The RSS will have to be RSS2 only as it will have to be mixed with an oStatus namespace to allow replies / echoes &c.
>> Perhaps a templating system for the feed itself would be in order, or is this something you want to leave out of ThinkTank
> ThinkTank produces an RSS feed. How a developer decides how to display that feed, and where, is up to them. We will provide some
> examples, that is all.
RSS and Atom are both representation of feeds, and thus Atom cannot be implemented as a "view" of the RSS feed.
By a templating system, I did not mean a templating system to change the visual appearance of the application, but rather the feed it outputs (Atom and RSS).

>> How to handle really large datasets? One extremely large RSS could become very inefficient.. Pagination?
> Likely.
Does RSS specify a way of paginating a feed as a part of the standard, or will a non-standard solution have to be implemented?

>> How should the two essential twitter features of #hashtags and @mentions be handled (if at all)?
> Remember that Twitter did not invent @, # or RT. Users invented them because it was necessary.
> Let’s just focus on gaining traction, the users will solve the other problems.
True, they didn't, but nowadays, users expect to be able to at least mention others, and as such, ThinkTank should provide this natively somehow in my opinion.

Jon

Reply RSS

Replies

append delete #1. Prenuntius

I'm loving this idea, my experience of the web revolves almost solely around RSS. I have the GReader subscribed to any website I'm interested in and then have an RSS client on my iphone that synchronises with GReader.

I actually avoid websites that don't deliever there updates as RSS. I just find it easier.

The flexibility of ThinkTank will no doubt be it's strength. I'd love to have the option to subscribe to 'Full Articles' or 'Headings Only' based on the content of the website. If you are going to want to go and see dynamic content or if you are only interested in some of the articles (*cough* Engadget *cough*) and want to ignore others, then you just subscribe to the titles and then click to read the full article.

So many options! I'd also love to see what people can come up with in regards to comment threads...you could be automatically subscribed to a comment thread if you make a comment on an article, etc...

Thanks for this Kroc.

append delete #2. Kroc

@Prenuntius ThinkTank will not be (at least not initially) a traditional RSS reader for your plethora of webcomics. We will first focus on the post / reply / follow mechanics to replace Twitter. As detailed in the article, with traction, I expect traditional RSS and Twitter features to merge, and a traditional RSS reader will be added. Having an RSS reader built in will also help people migrate from Twitter, as it will provide a valuable reason to always be within ThinkTank, and thus posting their thoughts.

append delete #3. Martijn

As far as the output feed is concerned, I would point towards Atom (atomenabled.org) and away from RSS2. One limitation I’ve always found annoying when it comes to RSS is where it requires the author element to be an email address (feed2.w3.org/…) for the feed to valid. It doesn’t seem like you would want to base ThinkThank around email addresses. (Of course there is nobody stopping you from going against the spec, many do, but you could just as well opt for Atom.)

The current oStatus spec actually makes use of the Atom namespace: gitorious.org/….

Atom also brings paginated feeds into view. There is a proposed standard over at the IETF called ‘Feed Paging and Archiving’ (RFC 5005). Section 3 talks about linking to separate feeds, inside a feed, as a form of pagination: tools.ietf.org/…. While they have included a section on RSS2 in that proposal (tools.ietf.org/…) take note that for it to work in RSS2 they include the whole Atom namespace into it first. So why start out with RSS in the first place?

That was me weighting in on the feed thing and Prenuntius’ questions around them. Hope this gives some food for thought.

append delete #4. Kroc

Thank you for the help Martijn. To begin with I will be looking at what rstatus is doing (which I assume must be Atom given what you’ve said).

append delete #5. Jose Pedro Arvela

In my opinion, I find Atom much more logically structured. So if it would be possible to use it, I'd recommend it.

Regarding hashtags, we could simply add each as a category of the entry.

append delete #6. Kroc

To me Atom is a type of RSS. RSS is some XML file that aggregators read. Whether the flavour of XML is RSS (the spec) or Atom, I don’t really care; I’ll find out when I get to coding it. RSS vs Atom debates are one of the most pedantic on the web.

append delete #7. Martijn

Thing is, Atom is not a type of RSS. Atom and RSS both are ways to serialise data in the form of an XML feed.

I agree that some people take the debate too far. Especially for blogs and the likes where it really does not matter. Both support elements for titles, links, descriptions and the likes.

However, our debate is concerning a whole platform. RSS 1 is not extendable so implementing separate specs like oStatus or feed pagination is impossible. RSS 2 allows extending through namespaces (cyber.law.harvard.edu/…) but many extensions will depend on the Atom namespace anyway. You could cut corners by going with an Atom feed (atomenabled.org/…) at once and skip having to define ``atom:`` on every XML tag.

For blogs, I’ve always recommended RSS. It is simple and should provide you with almost everything you will ever need. For an application like this I think Atom is the way to go.

I have not looked into the rstat.us software but their public feeds (rstat.us/…) use Atom as their base instead of RSS.

Would be interesting to hear what others think.

append delete #8. Kroc

I know all this already. I’m trying to drop a hint to move on from the Atom vs. RSS debate.

append delete #9. sull

This is good. very good. I know that i had mentioned my own related project/vision here some months back (rssgarden.com). I've been busy on other things and was starting to lose steam but am glad to hear that you plan to move your own ideas forward around RSS Messaging. This will help me to continue my rssgarden dev and make our software interop.

As for Replies across RSS... I was working on that component as an RSS Extension/Namespace and simply calling it "inReplyTo". It is implemented as regular comments on the feeds at rssgarden.com but the idea is to make it work across any domain/site/instance (and it actually does).
If you are interested in furthering the inReplyTo namespace and make it a part of ThinkTank... it would be nice.

Look forward to collab'n

@sull

append delete #10. sull

"Regarding hashtags, we could simply add each as a category of the entry."

Here is what I did with hashtags and RSS Item Categories:
rssgarden.com/…

As for @mentions and #hashtag hyperlinking... I utililized the javascript library based on "TwitterText":
github.com/…

Works well. Slightly modified for rssgarden usage.

One of the items I did not get to yet was the pagination stuff. I was looking into the "Feed Paging and Archiving" proposal too. Dave Winer has his own approach to it as well using a "microblog:archive" namespace but i did not finalize my own opinion of it:
scripting.com/…

Also, when I started working on inReplyTo RSS namesapce, i did review some prior art like atom threading but I felt it was overkill. I dont have documentation ready for what I did end up doing but the inReplyTo namespace is demonstrated in the feeds (including the replies feeds) at rssgarden.com. I was mixing identity into the namespace, which maybe was a stretch.

append delete #11. Kroc

This is useful information Sull, thank you. I’ll have a look into it. I don’t know fully how I am going to implement ThinkTank, I just know that it’s possible, one way or another, and I will cross the bridges as I come to them.

append delete #12. Adam Scheinberg

I still think many people will interact directly with your front-end. Decoding XML live is not very efficient, and RSS readers won't be pelting your web server. That's why I continue to think your best option is to store data in a format that unserializes fastest. unserialize() is faster for small arrays, but JSON is faster for large datasets and more portable. That's why I think the backend should really be JSON, which is far faster than decoding (and encoding) RSS or Atom, which can be generated on request and cached for X minutes.

Just food for thought.

append delete #13. Kroc

@Adam Scheinberg I can't say I fully comprehend your post, it seems conflicting. ThinkTank will likely use a SQLite database to store data. The RSS feeds will be generated from that rather than using RSS as the data store since I don't want a million-long RSS feed.

append delete #14. Zifre

I think there should be some way to optionally show replies in the public web interface (but not in the feed, of course). Some people (like Kroc) don't want comment threads beneath their articles, but many people are going to expect it once you remove the 140 character limit.

append delete #15. Kroc

Yeah, these are all sorts of things we need to think about with hammering out the interface. For simplicity, you could just echo the replies that you want to become public. There's no need to build every function into ThinkTank as you have to see things as many individual websites distributing information, rather than a centralised do-all app. ThinkTank will try to be as simple and to the point as these forums, other people can write more feature-laden systems.

append delete #16. Luca Degasperi

@Kroc using a SQL type database might not be the best thing to do, updates aren't highly relational data. Something like a document-based storage could be more efficient, even saving things as plain text on a file could be a good idea.

append delete #17. Luca Degasperi

Right now i think the best way to understand each-other is to produce a scheme of the parts that will be involved, focusing especially on the communication between different websites. Witch languages will be used during the process is the next step.

append delete #18. Kroc

JSON perhaps then.

The important thing is to know that it will be simple. Very simple. Like River of News (ex river.nicolasgallagher.com) meets Twitter v1 or rstat.us. I just want to get the concept nailed down so I can start publishing. ThinkTank will not be a feature filled client, but it will act as a clean starting point for people wanting to write their own or to add more.

append delete #19. Luca Degasperi

Then the main things to define are how the communication is done, how the authentication is handled and how the server should work.

#20. fyra

This post was deleted by its owner

append delete #21. pe7ed27

Is this idea still being worked on?

I've read your articles and am very keen to get involved somehow..

Personally I think simplicity is important... As an experiment I was considering cloning (to some extent) blosxom perl blog in php..

Index.php would be your public profile
Post.php (or whatever) would be the private side where you manage subscriptions and post new material..

While I havnt given much thought to #,@ etc I think that will work itself out...

Anyway... If I ever get something up and running ill post back

Reply

(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: Kroc, Impressed, Martijn