As you might have seen, the new version of abnib went live this afternoon. Just so I don’t keep getting the same comments over and over:
-
Right now, it’s a little fixated on the PST time zone. I’m not sure why this is, but I’ll fix this soon.
-
For some reason, it’s silently rejecting all applications for a username and password.
-
There’s no link to Abnib Gallery.
What’s new?
-
If you’re logged in (hah!) you can block posts by author. Later there may be other ways to filter and prioritise posts.
-
It automatically refreshes as new posts come in. No longer do you need to keep whacking "refresh" every time you get bored: if you’ve got JavaScript enabled, it’ll quietly check for new posts in the background and pick them up and make them appear on the page.
-
It integrates with the as-yet unreleased new Troma Night website, so you can see where and when the next Troma Night is at all times. Yeah, and this updates itself without refreshing too.
-
It’s prettier. I liked the old theme, but I know it wasn’t to everybody’s tastes, and the "it’s ugly" people were louder than the "it’s pretty" people.
- A couple of extra features that you can’t see because you can’t log in yet, either. Ahem. Will fix that soon, then.
I’d say ‘it’s prettier’ is quite subjective :-)
Can I make a stylesheet?
–Jon
Yes, it is. After all, I don’t think it’s prettier.
Yes, make a stylesheet. You should find that all the xhtml’s laid out in a nice way.
erm…i am logged in according to the top, so i guess thats sorted
a “classic” theme would be good, bringing the old-style abnib look to this version.
incidentally, any chance of an idea what’s behind it, tech-wise?
Yup; I’ll write a post about how it all works at some point in the future. For a quickie, though: it’s all Ruby FCGI and some mod_rewrite magic in the middle, Ruby cron jobs at the backend. XML support is provided by FeedReader, with a few extensions. Ajax is provided by Prototype and effects by Scriptaculous. All of the Ruby interfaces with a MySQL db using ActiveRecord.
Hold on, what do you need a database for? Are you sucking posts into a database?
–Jon
That question’d be best answered by telling you the schema. The tables (and some example data) are as follows:
Hope that answers your questions.
Oh yeah, I’m considering another table, linked to articles, called tags. The original theory would be that users could tag posts, for example, “geeky”, and then filter based on tags (e.g. “don’t show me posts that 2 or more people have tagged as ‘geeky'”). On the other hand, I just know that the first thing that’ll happen is you’ll start tagging certain posts with… whiny… fuckwit…
How long are articles cached for? If I remove a feed, are all the cached articles also deleted?
–Jon
Gareth, this is classic Abnib. Or more like it anyway; 3 was yellow and full of bubbles, and this is nice and clean-looking, like two was, but with cooler to-work-soon functions. I like.
Right now, they’re cached forever. If the feed or article-in-the-feed disappears, the deleted_at column is set and abnib doesn’t advertise the article any more. However, it’s still in the database: for the time being, indefinately.
It’s needed to be in the database to facilitate the (as yet unwritten) LJ “friends” notification, which involves a comparison between two feeds (one picked up while logged in to LJ, one not) to work out which ones should have their content replaced by “This is a friends-only post. Read it [link]here[/link].” Plus, I was considering having abnib cache old posts for longer than the more-frequently feeds keep them in their XML.
Surely it wouldn’t be too hard to remove all cached articles from a certain feed when that feed is removed? I think if someone removes their feed, for whatever reason, in a way they’re retracting their content so it should be deleted.
Yes, people can cache stuff locally, and yes Google caches it all anyway, blah blah, and there are a thousand reasons why removing content from the database if futile, but I still would have thought it is the right thing to do.
–Jon
When that feed is removed from abnib, yes. In fact, I’ve already implemented it. =o)
When they drop off the end of the feed; tougher, and I don’t want to. But I feel that I’ll be respecting the fact that it has been removed by not making it internet-accessible: it’s just like keeping copies of old RSS on my home PC. Nonetheless, in the longer term I’ll probably end up setting up an auto-culler to wipe the oldest crap at any given time.
“When they drop off the end of the feed; tougher, and I don’t want to. But I feel that I’ll be respecting the fact that it has been removed by not making it internet-accessible”
I think you should, and I don’t think you are.
I doubt anyone really reads beyond the top 30% of the page on Abnib anyway – most people check often enough that it isn’t necessary. I think once and article drops off a feed that it should be deleted from your database, (or, as a compromise, replaced by a stub which suggests the original URL, but doesn’t contain the content). I’m finding it hard to explain at the moment exactly why I think this – it’s not a concrete concept in my head, but for an aggregator to do more than a determined web surfer seems wrong.
Cacheing content forever is kind of violating the unspoken contract of RSS – something along the lines of ‘here is my content for you to view in a form which is more convenient to you, but it is still my content’. Yes, you *could* save everyones RSS feed on your home PC, but would you if you had to do it manually? Having a bit of software perform the same role seems a little wrong.
Unconvincing argument, I know, but I’m uneasy about this.
–Jon
Yes, you *could* save everyones RSS feed on your home PC, but would you if you had to do it manually?
No, I wouldn’t do it manually. I wrote a program for it. And it’s my work PC, not my home PC. The program is called Dog, and it’s been running for about 6 months. It even keeps copies of “friends only” posts and stuff, and tracks changes to posts. It’s pretty anal, but I like it ‘cos I’m RSS-OCD. It even screen-scrapes stuff that isn’t XML’d (LJ comments, mostly, but a few other interesting bits and pieces like Dilbert.com too). Some of the codebase acted as inspiration for abnib 5.
But nonetheless, I do see what you’re saying, however I find it interesting that to you, keeping a post ONLINE forever, but just as a link, is somehow better than keeping a copy of the post as last-seen OFFLINE.
Still, abnib’s a community site and the community aspect of it is important to me – which includes respectful behaviour. I’ll implent something like a 60-day deletion period next week (as much to save space as anything else: it gets big quickly!). I’ve always got Dog if I *really* want to, for example, grep Paul being random all the way back to the year dot.
Why does Abnib automatically generate a title? Sorry, hold on. I don’t mean ‘why’ (Jon and tgb may want to know but) I mean would Abnib break if it didn’t?
Why? ‘cos I have a pet hate for untitled blog posts, because they confuse me when I’m flicking through my work RSS reader and trying to work out what I may or may not have read while at home, and titles make that easier. Abnib having titles won’t directly help this problem, unless I switch to subscribing to the abnib feed (not likely for the time being), but I hope it’ll encourage people to pick meaningful titles, if only to stop abnib picking titles for them!
On the other hand, this could backfire – people may deliberately leave titles blank in order to have abnib pick ones for them, to see what they get. Hmm… might need a rethink…