stuff by antimatter15

Why? I donno. Wikis are awesome. I just want to see how the wiki concept could work for a site like this.

It’s not going to replace my blog, but it may be used for some documentation and stuff

This is somewhat random, but i’m 13 years old. I started the ajax animator 2 years ago. I’ve always sorta kept my age somewhat secret, maybe out of paranoia. I still feel sorta awkward blogging about this now.

So I just tried Safari 4 Beta, and I’m quite impressed, but it’s strange that it’s almost exactly like Chrome. It’s like Chrome’s not only based on Webkit, but Webkit is based on chrome. Sorta like Vista = OS X, Gadgets/Widgets, Search/Spotlight stuff. I’m somewhat annoyed about not being to close tabs with middle click, and how, unlike Firefox+TabKit, it only has that small possible tab space. Especially since I have a dysfunctional mental garbage-collection system, so I easily have >20 tabs at a time.

I Fail

Basically, in modern CMS development, there are 2 types of plugin systems. (that i care to talk about) A) creating a comprehensive API and isolating plugins into a plugin directory (wordpress does this, AFIK) B) creating patches to the source code through complex patching instructions (usually combined with an API too, and SMF sorta does this-ish)

The problem, is that neither is really developer-friendly (or at least me-friendly). Learning an API is boring, and I see recognize code better than man-pages. Documentation also is normally pretty crappy anyway (except for big projects like WP/SMF). Patching source code makes you manually define the context, line number, etc. It’s usually using a non-standardized system (XML files) and has many merge conflicts.

So how can it be improved? Well, the API part can’t really be improved on, but the latter one can. I think just hacking away directly at the source code is pretty decent. Because many times the changes are minor, and it doesn’t make sense to make huge new plugin files for it (though it would still work).

Instead, imagine something similar to a SCM like CVS or Subversion. Use patches in standardized formats (GNU Diff Unified format), so people can resolve conflicts with familiar tools, and reduce the chance of it happening. Have the CMS include a “developer mode” which enables the system to intelligently find the edits and build patches for.

What that becomes, is a simple, flexible pluggable, portable plugin system. (yay! a plugin subsystem as a plugin!).

It’s really just to streamline the (B) type of plugin system.