A minute before starting on replacing the backend on Pimki, I thought
I'd unofficially release a Pimki2 zombie out to the wild. The current
state of affairs in CVS is quite usable, but I will
change it soon and I don't want to punish users with another upgrade.
This is a "zombie" release as it's neither here nor there: it is no
longer compatible with Pimki 1.x, and it's not the DB-backed Pimki2.
But if you're into alpha software check it out - it contains a few fixes and polishings from the last few weeks.
As for the true blue Pimki2 (hey look, I can rhyme! badly!) - it's coming. I'm investigating writing an ActiveRecord adapter for KirbyBase myself (mostly myself - I plan to... er.. borrow much from Logan Capaldo's KirbyRecord). So I could both use ActiveRecord and the DB of my choice.
The results of the recent Pimki users survey
(published as soon as I get off my arse and collate them) stress
simplicity, one-click-install over everything else. As a developer, I
prefer using AR as it is integrated more tightly with the rest of
Rails. But of course I want the best of both worlds with the benefits
of KB (pure-ruby, plain-text).
So I'm attempting to write this myself.
Just don't hold your breath.
This also give me a something better to do than just wait for Instiki
to complete it's transition. This fork will apparently be the last time
Instiki core can be integrated as-is into Pimki. I plan to introduce
many code and schema changes, addition and tweaks that it will no
longer be possible to simply reuse Instiki (partly because Pimki needs
a simple database, and the
current options do not support AR:Migration). I will support importing
Instiki webs into Pimki, but not through the backend. I will continue
borrow features from Instiki, but the process will be more of a
reimplementation with hints from Instiki.
Back to the backend, if I fail to make KB and AR play nice (KB is not a
relational DBMS - it doesn't support SQL, which AR kinda assumes all
databases do), I'll reconsider my options. Instiki will come bundled
with SQLite, but even Alexy recommends MySQL "for any serious
scenario". User data is always a serious scenario to me. Plus, I
introduce way too much schema
changes between revisions myself, but SQLite does not support
AR:Migrations. So I might bite the bullet and write my own migrations
for every release, or I might use KB without AR.
Only time will tell, but feel free to make side comment in the mean time.
Previous Topic
