More medium/long term Typo goals

Remember this:

http://www.mail-archive.com/[email protected]/msg02284.html

Well, once I’ve checked in my current local branch which implements a
feedback specific state machine, we’ll have hit most of those goals,
so it’s time to think about a few more.

Outstanding/Short Term

  • Finish working through the implications of the new state machine
    based content ‘state’. Essentially, ‘published?’, ‘spam?’ and a few
    other flags are now delegated to the content’s state. Any behaviours
    on an object that do anything like:

    if self.published?

    end

    should have the ‘…’ turned into a method on the state objects and
    get rewritten as

    self.state.meaningful_name_for_some_behaviour

  • Something similar applies to some of the things the controllers are
    doing. Structural code (where controllers treat objects as nothing
    more than data structures) is anathema, behaviour should be pushed
    to the model where it makes sense. Controllers shouldn’t access the
    state directly, so state dependent behaviour should be pushed to the
    model first and then delegated to the state object.

  • Various of the delegated query methods could usefully be added to
    the model’s table, to help with searching. For instance, it would be
    useful for the feedback page to list only those items which are
    probably spam. Which means adding ‘spam’ and
    ‘classification_is_certain’ (lousy name, need to find something
    better) booleans to the contents table to help with
    searching. (Controllers don’t (and shoudln’t) know about the state
    objects, they just know about the query methods, so we need flag
    fields corresponding to the query methods which can be used as find
    conditions)

  • Make page caching work right. Still on my todo list, but not quite
    so urgent as it was. It’s in this section because it’s one of the
    things that haven’t yet been done from the last goals post.

  • Give the theming section a long hard look. Yay! We have Scribbish in
    the core now. However, theming still needs looking at. Wouldn’t it be
    great
    if you could just drop a theme in vendor/plugins and have it appear
    in Typo’s list? Wouldn’t it be handy to support theme specific
    configuration? Woudln’t it be useful if all this was documented?

  • Blog settings. Hmm…

  • Text filters not being controllers.
    Scott’s doing some work on making url_for work without having to get
    at the current controllers all the time. Once that’s done it should
    be a great deal easier to turn textfilters into models. Again, it
    would be good to be able to write textfilters so they could be
    dropped into vendor/plugins

New stuff

  • Authentication. I’ve posted about this before, but we should really
    support, at the very least, OpenID as well as our own internal users
    table.

  • Authorization. Once we can authenticate, we can authorize. Some
    blogs might choose require authentication before allowing anyone to
    comment, or automatically mark any unauthenticated comments as
    PresumedSpam

  • Pluggable Spam classification. Right now, when feedback is created,
    it’s in the ‘Unclassified’ state. Saving it ‘collapses’ it to one of
    ‘PresumedSpam’ or ‘PresumedHam’. The method for doing this
    classification is currently hardwired. First we check our own Spam
    Protection library, then, if it’s turned on, we ask Akismet.

    Which is all very well, but what happens if we decide we want to use
    Authentication as a factor in classification? What if someone writes
    a captcha plugin (which gets no nearer to Typo than vendor/plugins
    dammit)?

    So, we need to think about making the classification system into a
    dynamic pipeline attached to the blog. My current thinking is that
    this would be configured like sidebars are now (though possibly not
    at the model level, about which more later). The administrator would
    be presented with handy drag and drop interface and drag
    classification tools into a pipeline. So, I might have a pipeline
    that looks like:

    is_logged_in -> article_age -> blacklist -> akismet

    While someone else could have

    captcha -> article_age -> blacklist -> presume_ham

    each engine in the chain would look at the feedback and return one
    of :ham, :spam or nil, where returning a symbol halts the
    classification process, otherwise the feedback goes to the next
    classifier in the chain. Something similar could be done at the
    point that spam is firmly classified by the administrator; each
    engine would have their #report_as_spam/ham(feedback) method
    called and they’d do the reporting as they chose.

  • Multiblogging. I’m so in two minds about this. I think it’s going to
    happen, and I don’t think it’s going to have an enormous impact
    on the performance or copmlexity of the rest of typo. Introducing
    the blog object has proved to be The Right Thing, for all its
    teething problems.

  • RESTful API. I like REST. It just makes sense to me. But Typo
    isn’t all that RESTful. Article permalinks are, of course,
    sacrosanct, but pretty much everything else is fair game. In the
    long term, I’d like to see the back of admin/* in favour of moving
    administrative behaviour up into top level controllers and slightly
    more complicated access control. This is definitely branch
    territory, if only because the support for the sort of thing I’m
    thinking of has only recently gone into edge rails.

  • Migrations. Migrating is hard. It’s hard to keep the migration
    scripts up to date. So, I propose firming up the various message
    posting protocols we have, documenting them, and then sticking to
    them both in our controllers and any migrations we use. I envisage
    using something like the Atom API as our basic posting protocol.

  • Implement the Atom API.

  • Use the rails plugins directory. If you write textfilter, or a
    sidebar, you want some easy way of distributing it. And we want not
    to have to stick it in the core distribution. It seems that the best
    way to do this is to enable writing plugins that can be installed in
    the same way as any other rails plugin. I think that this can
    already be done, but it’s completely undocumented. We need to
    investigate this and, if it will work with the current state of the
    art, we need to write generate tasks to allow a plugin developer to
    do:

    ./script/generate sidebar|textfilter|theme

    and have a framework dropped in place so she can get on with the
    hard work of making it do something interesting.

  • Investigate other blogging engines’ plugin architectures. See if
    we’re missing any capabilities and what we’d need to do to import
    any useful stuff into Typo.

Hmm… that’ll probably do for now. Did I miss anything?


Typo-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/typo-list

Alastair R. [email protected] writes:

marked as presumed spam, merely unpublished. It took me a while to
realise that real comments were being published and that spam was
being held.

Except that’s changed with the last checkin. Now the presumed stuff is
marked as Spam? and Ham? and the confirmed stuff is marked as Spam and
Ham.

Also it seems that you (blog admin) need to go and remove unpublished
(ie spam) comments periodically. They seem to appear on the articles
otherwise. Or am I doing something wrong?

They shouldn’t be appearing on the articles (assuming they were posted
after the spam checking code went in). And one thing I mean to add is
an option to say that marking something as definite spam should just
report that to Akismet and then delete the feedback.

Some other suggestions:

  • Ability to configure multi-column sidebars

Wah! I knew I’d missed something.

  • A wordpress-like “dashboard” of recent comments, incoming links,
    stats (number of articles, comments, etc)

Hmm… we’re not doing much in the way of intelligent stats gathering
yet, so I’m not sure how easy ‘incoming links’ would be to do, but I
like the idea of a dashboard.

  • Ability to specify a license on a per-page or per-article basis
    (with a blog-wide default obviously) which would generate the right
    HTML and RDF for easy inclusion in themes. I’m thinking specifically
    of making it easy to add a creative commons license to a blog.

The problem with per-article licensing is how you sort out the
licensing of the front page. Probably doable with a sidebar that works
in a similar fashion to the current amazon sidebar (walks the list of
contents being rendered on the current page extracting book
citations/links and then builds the sidebar). But I’m still not sure
how it would choose the frontpage license. Ho hum. Worth thinking
about though.

Here’s one I forgot:

  • Investigate splitting the contents table into ‘contents’ (for pages
    and articles) and ‘feedback’ for comments and incoming
    trackbacks. The tricky part would be doing the split, and deciding
    whether it’s a requirement to maintain article ids (if you do decide
    to do that, you enter a twisty little maze of RDBMSes, all
    different, as you try to make sure that new ids get generated
    correctly once you’ve done the conversion) or to break any
    /articles/read/n type links. I’m beginning to think we need to do
    this, articles and feedback have a fair amount in common, but the
    differences are becoming more distinct with each migration.

Just a heads up, while I do intend on getting back into working on new
Typo development (I know I’ve been doing barely anything lately), but
for the next 3 weeks or so I’m going to be away (WWDC, vacation, etc). I
may be on #typo a little, but a lot of the time I won’t be around. I’ll
still respond to email, though.


Kevin B.
http://kevin.sb.org
[email protected]

Kevin B. [email protected] writes:

Just a heads up, while I do intend on getting back into working on new
Typo development (I know I’ve been doing barely anything lately), but
for the next 3 weeks or so I’m going to be away (WWDC, vacation, etc). I
may be on #typo a little, but a lot of the time I won’t be around. I’ll
still respond to email, though.

Continuing that theme, I’m off to Sidmouth Folk Festival 'til Tuesday,
when I’ll stick my nose in at the London Ruby U. Group
meeting. Expect me back on the Typo horse on Thursday or Friday next
week when I may be starting what I’m thinking of as a ‘new sidebars’
branch with a todo list that goes something like:

  1. Get rid of all the current sidebars and any infrastructure that
    supports them, simply support the current helper method for
    displaying them (I don’t want to break my themes, but the helper
    will probably just respond with ‘this space intentionally left
    blank’ for the time being.

  2. Experiment with various ways of providing sidebars that don’t use
    components to do their magic. Which thought is, even now, hurting
    my head.

  3. Work out which one is least horrible and most testable.

  4. Commit it to the trunk, port our currently supported sidebars to
    the new scheme and make everyone who has their own sidebars to
    support cry.

  5. Wait 'til everyone has stopped crying and ported their sidebars

  6. Write a handy adapter that makes old style sidebars work with the
    new scheme.

Please note that steps 2 through 6 are highly speculative.

I mostly agree with Piers. Here’s a short version of my list (short,
because I’m on vacation this week):

  • Finish the url_for cleanup. All Content model objects should
    support a permalink_url (or similar) method that returns a link to the
    permalink for the object. Maybe an edit_url and delete_url,
    too–that’d clean up some of the views.

  • Helper cleanup–there are zillions of duplicate ways to get URLs and
    so forth buried in out helpers. Clean them up, standardize, optimize,
    and document.

  • Add rdoc where appropriate.

  • Query optimization–the front page (sans sidebars) should take 3
    queries: blog_id, article count, page 1 article bodies. We’re down to
    ~30 now, from 300 late in the 4.0 dev cycle. Sidebars should be
    cleaned up where possible, so they’re fast.

  • Optimization. Faster, faster, faster. With less RAM.

  • Remove components. They were a nice idea. At least according to
    the Rails docs. However, it’s unclear that anyone else uses them for
    anything. We’ve certainly found substantial bugs in them that no one
    else caught. Plus, they’re slow. Make it possible to bundle
    sidebars, themes, and text filters into Rails plugins, and build some
    sort of infrastructure to make this easy for users. Then move most of
    the non-core sidebars out of the main tree.

  • Clean up the admin UI. Everyone has ideas on this. I’d love to see
    a few mockups.

  • Threaded comments. I miss mine. I have a model that is fairly
    simple, I’ll show it to people later.

  • OpenID consumer and producer. Typo should be able to use OpenID to
    authenticate comment posters and act as an OpenID producer so people
    can use their blog as their identity.

  • Lightweight permissions model. I’d like to be able to keep
    commenter preferences in the user table, so we can send out email
    notifications when people follow up on their comments. I DON’T want
    a 50-table complex permissions model.

  • Multiblog support. Ignoring the permissions problem, we’re 95% of
    the way there already.

  • Better Jabber/XMPP support. I’d love to be able to send Atom over
    XMPP. There’s a spec for it out, although it has issues. I’d really
    love to merge OpenID, some sort of Typo registry website, and XMPP
    to make cross-Typo comments and trackbacks much more powerful then
    they are now.

  • Atom Publishing Protocol. I love the Atom publishing protocol. Go
    play with the Google C. API for an example of what APP is able
    to do. There’s a bit of a problem with it and Typo, though–our text
    filter model doesn’t really fit into APP’s view of the world. I
    talked with Tim B. about it a bit at OSCON, and I think I see a way
    out.

  • Standardized import and export scripts. I’d love to be able to
    say ‘typo import /some/path wordpress /tmp/foo’. Similarly, we could
    standardize some sort of Atom-based Typo export format.

In all honesty, I don’t expect to get most of this done for 4.1. I’d
be happy if we could do a bit of permissions work, fix the URLs, ditch
components, and speed things up. I’d really like to have 4.1 out
during 2006.

Scott

Actually, we have atom exporting already (I assume by exporting you mean
a feed). The atom support we need is the atom blog API. I have a branch
sitting around (on the comptuer in a box winging its way back to MA that
I won’t see for two weeks) that was intended to work on that, but I
didn’t get much work done back then. If nobody’s taken it up in the next
few weeks I may re-start my attempt.

On Fri, Aug 04, 2006 at 08:00:23PM +1000, Alastair R. wrote:

much like rocket science.

I’m intending to just wade in, hacking and slashing, but any
suggestions appreciated.


Kevin B.
http://kevin.sb.org
[email protected]
http://www.tildesoft.com

On 03/08/2006, at 2:55 AM, Scott L. wrote:

I mostly agree with Piers. Here’s a short version of my list (short,
because I’m on vacation this week):

[… snip a fantastic list of enhancements …]

Is there any low-hanging fruit for rails- and typo- newbies to
attempt? I’m willing to have a look at Atom-based exporting (seeing
as I raised it on your blog :), on the assumption that it is not too
much like rocket science.

I’m intending to just wade in, hacking and slashing, but any
suggestions appreciated.

I’d love to see an Atom-based blog export/import standard. Does
anyone know any of the WP guys?

It seems to me that the rational thing to do would be to have a “pure”
Atom feed, including HTML for each entry, and then add an ‘export’
namespace and use tags like ‘export:description’ to include the
original markup, as well as other fields that don’t map into standard
Atom (comments open, trackbacks, etc). I’m not sure if static
content, comments, and trackbacks would be better as more entries with
a special type flag or as their own tag.

I suspect that we could get a few prominent non-Typo XML people
involved in this pretty quickly, if we can sit down and produce a
first draft of the standard.

Scott

On 06/08/2006, at 4:24 PM, Kevin B. wrote:

Actually, we have atom exporting already (I assume by exporting you
mean
a feed).

Actually, I meant more than just a feed.

I don’t know about anyone else, but I find it a lot easier to put my
data somewhere that I know I will be able to get it out again. This
applies especially for web applications hosted by third-parties,
where export facilities are a must before I’ll even look at it, but I
believe it is generally a good practice. The ability to export is
something that is missing from Typo. You can get your data out again,
but it’s in the database schema du jour.

Hence the motivation for an export facility for Typo. This is an
escape hatch, if you will, for migration to an unspecified future
blogging platform.

At present there is no common interchange format for blog content.
The closest we get is Atom, and I’m not even sure whether that is
entirely suitable for representing all of the interesting content of
a blog. Anyway I think it’s worth having a crack at it.

Unlike the current Atom feed, the Atom export facility would:
a) include a complete archive, that is all of the articles, pages,
comments, trackbacks, etc in the blog
b) use the ‘raw’ formatting (eg markdown) instead of HTML
c) probably ignore attachments (unless someone has a better idea?)

On Scott’s blog I mentioned the possibility that this could be
expanded to fill the role of a backup/restore format, and he was
fairly sure he wanted these to be completely separate. Which seems
reasonable.

On 08/08/2006, at 1:36 AM, Scott L. wrote:

I’d love to see an Atom-based blog export/import standard. Does
anyone know any of the WP guys?

Sorry I don’t. And not to put a downer on this idea but one of the
reasons I migrated to Typo from WP was that WP had been sitting still
with its Atom support (it is still on 0.3 AFAIK). But yes we should
get the other blogging engines involved.

It seems to me that the rational thing to do would be to have a “pure”
Atom feed, including HTML for each entry, and then add an ‘export’
namespace and use tags like ‘export:description’ to include the
original markup, as well as other fields that don’t map into standard
Atom (comments open, trackbacks, etc).

Yep, except probably “typo:” might be a more appropriate namespace
prefix (yes I know these aren’t signficant :).

Also, using the original source of each entry could be used instead
of the resulting HTML and it would still be valid Atom. This might be
simpler for the user to select whether they want the raw or cooked
(ie HTML) content to be included in their export, rather than have
the importer work out which of two alternative representations is
more compatible.

I’m not sure if static
content, comments, and trackbacks would be better as more entries with
a special type flag or as their own tag.

Yes, another tricky one. Comments and trackbacks would also need to
indicate which article (or page?) they are attached to.

I suspect that we could get a few prominent non-Typo XML people
involved in this pretty quickly, if we can sit down and produce a
first draft of the standard.

Agree.

I can volunteer to make a start on this.

On 08/08/2006, at 9:38 PM, I wrote:

Yep, except probably “typo:” might be a more appropriate namespace
prefix

… but not if we want this to be used by other blogging engines,
which is of course the point of the exercise.

Sorry I don’t know where my head was when I suggested that.

I agree to go with “export:” as a namespace prefix for now.

:-).

I know a few of the 6A folks, but I’m not sure that they’re the right
place to start with this. There has to be a blog-implementers list
out there somewhere.

Scott

On 8/8/06, Dominic M. [email protected] wrote:

I agree to go with “export:” as a namespace prefix for now.

No. You go with “FGYRKJY” as the prefix (because it doesn’t matter) and
http://some.where.central/export” as the namespace URI. :slight_smile:

:-).

Scott

I really should re-read it, but I’m pretty sure the Atom blog API
stuff deals with getting the raw data out from the blog so you can
edit it. And you can request more than just the last 10 or 15 posts or
so - you can request chunks going back until the beginning.

So I would hold of discussion on this until we can verify whether the
Atom blog API does in fact do everything you want.

On Tue, Aug 08, 2006 at 10:44:53PM +1000, Alastair R. wrote:

I agree to go with “export:” as a namespace prefix for now.
No. You go with “FGYRKJY” as the prefix (because it doesn’t matter) and
http://some.where.central/export” as the namespace URI. :slight_smile:

-Dom

I just read the APP spec and I couldn’t see any discussion about raw
vs cooked (as I like to call it) content.

I think it is unlikely that they (APP spec writers) will add
additional fields to the Atom entry document as alternative
representations of the content, but hey that’s just my guess.

However it is pretty clear that APP builds upon Atom, and the
additional functionality provided is not particularly relevant to the
task of exporting blog content. For example the entries in a
“collection” are retrieved as an Atom feed document, with only minor
extensions: the paging extensions, which are largely irrelevant for
our purposes, and the “publishing control” extensions, which look
useful (“draft” status for entries).

The point being that we probably don’t need to wait for APP to be
completed before starting work on blog exporting using Atom. Which is
good, because I have almost finished a first draft proposal on this
subject!

I don’t remember seeing it when I read the spec last year, and Tim
Bray thought that filtering and formatting was a known problem when I
asked him a couple weeks ago. It doesn’t really make a difference in
this case, though-we’re talking about serializing the whole blog to an
Atom-based XML file, which is kind of orthogonal to the Atom
Publishing Protocol. I don’t believe there’s any standardized way to
handle comments and trackbacks via APP, so building a generic blog
sync tool via APP isn’t really possible, either.

Scott

The nice thing about XML specs like Atom is that you can trivially
extend them with namespaces. The down side is that XML is a pain, and
namespaces are doubly painful. At least they’re easy to parse.

Scott

As a follow up to this goal, I’d like to see better error handling in
the sidebars. I’ll help too – I just wanted to talk over the issue
before writing a bunch of code in seclusion.

I was recently contacted by someone who was having trouble configuring
their sidebars, and most of the problems came down to bad input values.
He was frustrated because the values were accepted, but nothing was
displayed in his blog, and no warnings appeared in either the admin
console or the server logs.

After looking at some of the RSS based sidebar plugins (Flickr,
delicious, etc), there’s a lot code that looks like it was
copy-and-pasted. I’ve started figuring out how to refactor the common
RSS code into one place. Sometime in the next few days I will have
collected enough coding time to have a patch available for review.

Piers, let me know how I can help best without stepping all over your
toes.

Thanks,

Tim

Piers C. wrote:

Continuing that theme, I’m off to Sidmouth Folk Festival 'til Tuesday,

  1. Wait 'til everyone has stopped crying and ported their sidebars

  2. Write a handy adapter that makes old style sidebars work with the
    new scheme.

Please note that steps 2 through 6 are highly speculative.


Timothy F.
http://digital-achievement.com
http://edodyssey.com

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs