I am in Chicago this week, attending HostingCon 2007.

I'm not really attending the sessions actually. I'm mainly here to talk with the hosting companies about how we can better run b2evo on their shared hosting plans. Because that's actually how most b2evo users run it! (Ok, I'm also here to visit Chicago, which btw is pretty impressive... in many ways... but you'll have to check out my personal blogs for that kind of stuff )

One issue, of course, is to make installation as seamless as possible. Most of our hosting partners already offer easy installation method through cPanel + Fantastico Deluxe. However, in many cases there is room for improvement and we'll work on that. More on this later...

The other big thing, of course, is PHP 5!

You may have heard about the PHP group abandoning support for PHP4 at the end of the year. (Was bound to happen...)

You may have heard about the gophp5.org initiative. (Feels like a guerilla operation to me...)

And you may have read about some popular software strongly sticking to PHP4. (Huh!? What about supporting NCSA Mosaic?)

I'm sort of in the middle...

On the one hand, I reckon that the PHP 5 features would make the development of b2evolution easier and that it would even improve performance in some situations.

On the other hand, I also reckon that PHP 5 is not enabled by default on mosts hosts and that trying to use it involves more setup work on the user's shoulders.

And finally, I'm pretty disappointed with the PHP group who created the PHP4 vs PHP5 incompatibility problem in the first place. I still strongly believe there would have been an easy solution to the upgrade path.

(At this point I have to plead guilty for introducing my own lousy upgrade issues on some previous versions of b2evolution. However, I pledge to make upgrades easier after 2.0.)

Anyway, the PHP5 situation being what it is, my belief is that we can work it out with the hosting companies!

Having talked this through with a couple of them it turns out that:

1. They all support PHP5, but in different ways. BlueHost has it enabled by default (nice!). Most of the others support it optionally. Sometimes you have to request it from tech support, but most of the time you can enable it through .htaccess or your own php.ini ... that is, if you're geeky enough for that kind of stuff! Anyway, the bottom line is: there is no standard way to enable PHP5 from one host to another.
2. Mosts hosts actually did not realize that it is an issue to the development of software apps... since we somehow managed to still make it run on PHP4 so far.
3. Many hosts actually did not realize that the lack of a standard mechanism to switch to PHP5 is a problem for seamless install.
4. Many hosts actually did not realize that all PHP applications today, including b2evolution of course, do already work on PHP5 as well as PHP4.

After discussing this thoroughly with several hosts, I do believe there will be an acceptable consensus: most hosting companies seem to be willing to start to roll out PHP5 by default for all new accounts, a couple of months from now. (The current customers would still need to ask their tech support to be upgraded).

So I do have hopes that PHP5 will actually make it mainstream this year at all major hosts (and that the smaller ones will automatically follow). If it doesn't... We could still join the gophp5 "guerrilla" thing. However, I'd really like not to force PHP5 on the users as long as it requires an extra step in the install process.

Regarding b2evolution 2.0: we're still compatible with PHP4 of course. I personally run half of my servers on PHP4 and the other half on PHP5, just to make sure it works on both

Now, being in the US with the tiny laptop makes it much harder for me to actually wrap up that 2.0 release... but I haven't given up yet! Stay tuned

-Francois.

b2evolution is actually an evolution of the b2 blog software. Thus, a significant part of the codebase is b2 legacy. As of today, b2 legacy is a little less than 50% of the whole b2evolution code.


Every now & then I read these quite irritating remarks about some other b2 forks supposedly being so much better because their authors are planning to rewrite it from ground up someday. :crazy: Duh!


Beyond the intrinsic irony of this statement, I'd like to explain my position about this: I do not believe the usage value of software lies in its codebase!


Actually, I have experimented the rewriting path myself about 12 years ago. I had developed a piece of software working very well with lots of happy users. However, I decided that having written this software in GfA Basic wasn't good enough and rewrote it from ground up in C!


This was an unvaluable move for me to learn the C language (and a couple of other things I wanted to experiment with, like the GEM environment), but regarding the software, the new version - while significantly nicer - never reached the usage value of the previous one.


The product and the users would have benefited much more from me spending all this time adding new features to the existing codebase instead of reimplementing the same ones differently. However, as a developer, I personnaly benefited more from reimplementation.


See how precisely this translates to b2 and its forks?


Now, please give me a break with this rewriting crap! Anyone talking to you about rewriting doesn't actually care about the community but about himself. :lalala: I don't blame that - we work for free - I just don't want it turned into ridiculous "marketing" arguments.


Also, please don't get me wrong: I am not saying the legacy b2 codebase was all clean. The b2evo dev team has actually rewritten more than 50% of it in order to achieve better maintainance. But we don't advertise that. We take far more pride in providing new features on a regular basis.

Blogs, as most current web applications, need to address the server-side caching issue in order to reduce webserver load.


It looks like most people are quite happy with caching static versions of their pages for some defined amount of time. This method has often been called something like ~`half-baked/half-fried'~ in reference to the long running baked (static) versus fried (dynamic) discussion.


I'd actually call it ~`baked on demand'~... but regardless of what name we use, I would not be satisfied with this.


I have actually done some experiments caching my blog homepages which is enough to significantly reduce load, but this really makes them too static for me. I do want to log some stuff in realtime, I do want new user comments to show up instantly, and most of all: I do want the page to be customized for each user: display new posts since last visit, display his personal choice of categories, etc... Caching a whole page for every possible combination seems plain stupid. (And it is! )


Actually, the only smart caching mechanism one can be satisfied with in high-end web-applications is block-caching. As a matter of fact, a web page can actually almost always be considered as an assembly of different blocks. Some are static, some are dynamically updated several times a day, some are related to the user himself and some are so dynamic they change everytime the page is displayed, no matter what! By caching each of these blocks individually when it makes sense and rebuilding only those necessary at a given time, you can then reconstruct your whole page dynamically significantly faster than if you had to reconstruct all blocks from scratch everytime.


And there you have it: performance and functionality. Yeah, Okay, I know... it's also much more complex to implement than any other caching mechanism...

Sometimes I think debugging pingback is the greatest pain... ever!


[Please excuse for this disguised live test ]


Actually, there is in XMLRPC for PHP there is this cool xmlrpc_client.setDebug() method that helps a lot. I thought that would make my day for a while.... That was until I realized I had just spent half of the day debugging two bugs in the b2 pingback implementation! >:-(


This would have been far more efficient if the original developper for this (Mort) had finished the debugging in the first place... and this is precisely why I'm not rushing my own b2evolution out before I iron out as many quirks as I can!

• No referential integrity
• No transactions (at least not enabled by default so hosting providers would have them)
• No subqueries in DELETE statements
• No UNION statement (can you believe it?)
• and of course no triggers of any kind...

Not that I think mySQL is a bad thing... just that I don't understand how this can be called 3.23! Actually, 0.3.23 would be more appropriate!

I'm so close to making 0.4 (some call it 4.0 ) a requirement for b2evolution!

Information overload!


The issue has been hitting weblogs quite a while ago, and that's why we have RSS. But stil, we need to narrow down the flow of information our aggregators feed us with daily!


One solution would be Bayesian Filtering in the aggregator.


As far as I am concerned, I will be providing category selection on my RSS feeds shortly (as weel as an aggregated feed for all my blogs). That should let you aggregate only the subjects you care about.