Taking Flight

Chyrp is being converted to a language-agnostic blogging engine specification, instead of a standalone software distribution.

This means that developers (quite a few of you guys [gals?]!) will be able to — encouraged to — make implementations of Chyrp in other languages, frameworks, what-have-you. I’ll be leaving the PHP development to Patryk Zawadzki, who’s been dutifully making tickets, patches, and suggestions at the Trac for the past week. He knows what he’s doing, trust me.

I’ll still be around, supervising development and adding stuff myself - but right now I’m more interested in a Ruby port (me and PHP have broken up). I know quite a few people are interested in doing a Python implementation, as well.

A brand spankin’ new templating engine is in the works by our buddy mitsuhiko in #chyrp. The first implementation will be in PHP, and it will then be created in Ruby and Python. This new engine will be used for Chyrp themes, so that they work across all three of these languages. While PHP, Ruby, and Python are the three languages it’ll initially be made for, I’m sure he’d be fine with people porting it to others.

Wait. What about extensions?!

The problem with doing this is that Chyrp is nearly 100% dependent on modules. A PHP module won’t work with a Ruby Chyrp, etc. To remedy this issue, a specialized Porting area will be created in the Chyrp site, where module developers can work with one another to port their module to other languages.

It sounds complex, but the Module and Feather engines are designed to remain similar across various languages. They use object-oriented code, which can easily be transferred into many languages, such as Python and Ruby, with a bit of work.

When you upload your module to the Extend section, the archive should include directories named for each languages, for example:

  • php/ ** module.php ** … stuff …
  • ruby/ ** module.rb ** … stuff …
  • python/ ** module.py ** … stuff …

A user will then be able to select which language they would like it in, and it’ll download an archive with just that language.

How can I get involved? I want Chyrp in my favorite language!

Wait for the PHP5 release first, that’s what the spec will be based on.

Everything is done manually, so you’ll just have to e-mail me the language you’re making it in, and what username you want for SVN. You’ll get your own SVN subdirectory, and you’ll have a bit more power on the Trac.

For example, if you’re making a Python Chyrp, your SVN url would be svn://toogeneric.com/chyrp/python. You would be able to manage milestones and tickets in the Trac, and components would be made for Python, like so:

  • Python: Core
  • Python: Feather
  • Python: Module
  • Python: Theme

(If you want more than that you can request them, if your implementation is a bit more complex.)

As for Milestones, you will have to add “Python: ” to the name, e.g. “Python: 1.5”. Please don’t mess with anything from the other language projects. This is all an honor system.

Of course, you’re free to manage your Chyrp language implementation on your own terms. This is just the standard way, so that everything is centralized.

07:44 PM | 23 Comments

Comments

  1. I’ll admit I was worried when you said Chyrp wasn’t going to be PHP anymore, but this seems like a fair compromise. The templating engine sounds cool.

    Cameron on

  2. PDO does the right thing by ignoring magic_quotes_gpc—even if it looks like a value has been auto-quoted, there’s no way PDO can be sure it has, or even that it came from get/post/cookie.

    magic_quotes_gpc should never ever have been added to the PHP core in the first place though.

    How are arguments going to be passed to the (language-agnostic) templating engine? JSON?

    Michael S. on

  3. Michael: Yea, that issue has since been fixed by Patrys, so, woo. Input values are stripped automatically if it’s on, so Chyrp doesn’t have to fret.

    It was just really annoying to have to encounter that and figure out it was something so simple. They could have at least had a mention in the documentation, because it’s obviously different from mysql_escape_string, which most people are using. That was my main frustration. It’s not the only thing that caused me to lose faith in PHP, it was just the final straw.

    The templating engine will have values passed to it, as seen in “this test file on line 14”:http://chyrp.net/trac/browser/twig/php/test.php?rev=33. None of this is finalized though, as it’s all being (rather rapidly) developed by mitsuhiko.

    I forgot to mention, mitsuhiko is the guy behind “Jinja”:http://jinja.pocoo.org/, so he knows his stuff. It’s pretty lucky that he was in the channel when we were discussing the templating issue.

    Alex on

  4. Hey-oh!

    hier on

  5. I am unsure as to what to make of this news. I was happy to have found a great alternative to wordpress, especially given how prolific the PHP platform is. With that in mind I hope that PHP development does not stagnate.

    I am a little concerned about the way Rails does stuff especially with regard to JS libs and so forth so will be sticking to what I am comfortable with (ASP.NET anyone….)

    Anyway I think I will continue with the PHP implementation since I have already started working on a project that depends on that. I will continue to devlop and extend whay I am working on at the moment and if anythinng good comes of it I may well release some of the code.

    It will certainly be interesting to see where this goes , it certainly is a unique proposition.

    To Alex and the team good luck and I may see you on IRC soon.

    Matt on

  6. this is a really cool idea. if you know php , but want to learn python - download chyrp and compare the source code. same with ruby v python. or ruby v php

    mr ed on

  7. That’s really cool to hear that you want to do a Ruby port. I thought about doing one myself, but now I can just help you out I suppose.

    Matt: I’m not sure what you mean by “I am a little concerned about the way Rails does stuff especially with regard to JS libs and so forth…”. You can use a JS lib with Rails just like you can with PHP…

    Jeremy on

  8. @Jeremy, Yes your absolutley right. I guess I was referring to the default rails configuration with Prototype and the inline js that rails helpers provide. Ultimatley. Regardless of such things I will be keen to watch how things develop and help if I can.

    Matt on

  9. Matt: I’m not using Rails, just pure Ruby + Rack + DataMapper. You can see what I’ve done so far with git:

    @git clone git://toogeneric.com/chyrp/ruby.git@

    Also, rest assured that the PHP branch won’t stagnate. If someone else isn’t working on it I probably will, especially since it’s what the new spec will be based on.

    Alex on

  10. “Also, rest assured that the PHP branch won’t stagnate. If someone else isn’t working on it I probably will, especially since it’s what the new spec will be based on.”

    Alex, do you mean through the PHP5 release, or carrying forward? I am confused too by the notion of a blog engine spec — will you regard the PHP5 release as “feature-complete”, thus creating a static spec for porting to other languages? Or will the PHP5 “spec” iterate, so a Ruby port could be “Chyrp 1.5 compliant” but not yet “Chyrp 1.6 compliant” ?

    Also, given that you are the “figurehead” of Chyrp, do you ever see the ruby port becoming the de-facto spec, if that is where you are concentrating your development efforts? Or should discussions/implementations of new features for the Chyrp spec move to an external document/wiki/whatever, and from there each language’s port can incorporate.

    misterbrandt on

  11. misterbrandt: The PHP5 release. Basically, the first spec will be based on it, from then on the spec will be independent, and will iterate as new ideas and enhancements come along. At that point it’s up to the developers to update, just like anything else.

    No language implementation will become the de-facto spec. This is just a one-time thing to get started, since the PHP5 branch is already there.

    Alex on

  12. This is a good idea, but I’m worried we’ll end up comparing tables trying to figure out which version is the best.

    Julian on

  13. Alex, thanks for clarifying it will all work… Will you host all the projects on chyrp.net ? Thoughts on how the spec will exist and be contributed to? up until now, everything has run through you, which has made for a nice, lean core project.

    misterbrandt on

  14. I’ll host as many as I can (256mb can only do so much), but it won’t be enforced. Developers are free to host and provide their implementation on their own terms, if they wish.

    As for the spec, that’ll be the hardest part. I’ll probably do it myself since right now I’m the only one who knows the inner workings inside and out. I’ll make a trac dedicated to the Chyrp spec where people can submit proposals.

    I wonder if there’s any sort of “standard” spec format when it comes to published documents on the web. Kind of funny to ask that: “Is there a spec spec?”

    Alex on

  15. @Alex, Glad to hear that the PHP version wont stagnate, also more intrigued at the news that you’re using more Ruby rather than Rails. This could well be the incentive I need to get some experience with it.

    Thanks for putting up the link to your work so far. Can’t wait to have a look.

    Matt on

  16. Alex RE: specs, have you read Joel Spolsky’s series on specs? Part 1 is “why”, which I think you’re beyond, but Part 2 is here, and includes a sample. Maybe food for thought?

    misterbrandt on

  17. misetbrandt: Thanks for that, looking into it.

    Alex on

  18. @Alex: […] also more intrigued at the news that you’re using more Ruby rather than Rails

    Rails (precisely “ruby on rails) is a framework to program web applications in ruby. Saying “you use more ruby than rails” doesn’t make sense. You don’t need to use rails to program web applications in ruby. Rails is just some kind of help to program.

    Edouard on

  19. Will the “language-agnostic”-ness apply to the DB backend as well? ie will we be able to use non-MySQL databases?

    Personally I’m interested in seeing SQLite support.

    ketsugi on

  20. ketsugi: That all depends on what they’re using. For example, in PHP we use PDO, which is database-agnostic. However, we’re coding the SQL queries directly, which aren’t always compatible with every database adapter (e.g. SQLite, Postgres, MySQL).

    In other cases they might be using some sort of ORM such as DataMapper. That doesn’t involve writing SQL directly, and they’re already known to be adapter-agnostic. In fact, Chy.rb is being done with SQLite while I develop it.

    Alex on

  21. it’s really cool blog enginne i’m ever found.maybe i find the day too late.~

    问道推广人 on

  22. pretty cool idea! i must support what ketsugi proposes, too!

    fauno on

  23. asd

    test on