Lyceum-users mailing list

[Qiming Li <liqiming AT gmail.com>]

Hi John,

I have used a Lyceum-based blog site (as a user) for some time, and I
have recently been trying to improve on the Lyceum 1.0.3 code base for
a couple of weeks in an attempt of building a small-to-medium blog
site for a friend. This message is definitely a great great news to
people who really like Lyceum, like myself.

The main advantage of Lyceum to me, not surprisingly, is the clean
database schema. This results in a fixed number of databases and
tables, regardless of the number of users. Now, this is very important
to me because I have to host the blog site on a shared hosting server,
which does have a limit on the number of databases you can create. I
think the same applies for a few friends of mine who have their own
forum/blog sites.

The main disadvantage of Lyceum compared with WordPress (or MU), is
not the feature rich-ness (frankly I don't care too much about fancy
features), but the difficulty in the localization. In WordPress,
almost all text are enclosed nicely in the standard php gettext format
(i.e., __() or _() or _e()), but Lyceum has many English text lying
around without using gettext. During the past few weeks I had to go
through the files one by one and fix all those text before I could
properly localize it (I still haven't finished yet). There is even a
bug in php-gettext that prevented translation showing up on my service
provider's machine (btw, php-gettext itself doesn't seem to be
active).

Another (minor) disadvantage is that, sometimes a seemingly simple
question requires a relatively complex database query. Take the portal
for example. To display the list of all blogs sorted by their most
recent posts, we sort posts by date and find out which blogs these
posts belong to. The first part is easy, but to find the blog a post
belongs to you will have to do inner join of 5 tables. I'm not sure if
the performance hurts, but this definitely makes it quite difficult to
read (it took me a few hours to understand what the code is doing).  I
understand that to keep the schema normalized, there shouldn't be any
transitivity. But considering that the portal is an important
interface for the blog site I'm working on, which could be viewed most
frequently, I'm wondering if the schema could be improved to make this
easier/faster.

What makes it worse is the column names are sometimes confusing. For
example, in the "options" table, there is a "blog_id" and a "blog". It
took me quite a while to realize that the "blog" is actually the "id"
of the "blog", not the "blog_id"!.

Having said that, I still prefer Lyceum where a query can always be
constructed with manageable complexity. WordPress/MU could be much
worse in this respect.

I'd really appreciate your effort in maintaining Lyceum and keep it
up-to-date. I might end up doing that myself if time permits :-)

Qiming

On Thu, Feb 12, 2009 at 2:41 PM, John Joseph Bachir <jjb AT ibiblio.org> wrote:
> Lyceum users,
> Below is an overview of the status of the Lyceum project, and a request for
> feedback from you on where you would like Lyceum to go. If you don't have
> time to read the entire thing, please skip down to the questions at the
> bottom and send some feedback, either to the list or directly to me. Thanks!
>
> --------
> As many of you have surely noticed, Lyceum development has been essentially
> nonexistent for the last year and a half. The last point release was a
> bugfix in June 2008, which is still working off of the WordPress 2.0.x
> branch.
> The reason for this can mostly be blamed on the somewhat cliché narrative of
> the open source developer getting a job and a girlfriend and letting his
> brilliant project go unmaintained. Another significant factor is that
> Lyceum's primary competitor, WordPress MU, has grown into a respectable and
> consistently maintained project. While users continue to tell me that they
> find Lyceum easier to install and in various ways more intuitive than MU, it
> has more-or-less feature parity with Lyceum...
> ...except, of course, for the database schema. Lyceum's schema is
> normalized[1], MU's is, roughly speaking, sharded[2]. For massive
> installations such as wordpress.com, a sharded schema is preferable. A
> normalized schema is preferable for everyone else. A normalized schema
> offers advantages in performance, ease of upgrades and administration, and
> vast opportunities for developing plugins and features which can access the
> entire set of data in the installation.
>
> "Show me the last 10 posts across all blogs" is impossible in MU without
> maintaining and accessing a separate, redundant index table at the
> application layer. In Lyceum it is trivial and fast, even for thousands of
> blogs.
> Regardless of these advantages, the effort of maintaining Lyceum must be
> matched by demand. So I find myself at a crossroads, deciding whether to
> pick the project back up, or let MU be the only option.
>
> So my question to you, users, is this: What value does Lyceum hold for you
> today? How many of you out there chose Lyceum over MU mainly because of the
> schema? What other reasons do you have? What do you like and dislike about
> Lyceum?
> If I choose to resume Lyceum development, here are the two initial phases of
> development:
> :: Phase 1 - simply bring Lyceum up to the current version of WordPress
> I have two options for doing this. The first is to continue developing
> Lyceum as a branch of WordPress. The second, and more likely option, is to
> start from scratch using the WordPress MU codebase, keeping all of its
> features and merely normalizing the schema.
> Either way, I could get Lyceum back on its feet in 2-4 months of
> development. And don't worry: even though the codebase would be wildly
> changed, there would be a fully-supported upgrade path from previous
> versions of Lyceum.
> After getting the codebase contemporary with WordPress, applying future
> WordPress updates to Lyceum would be a non-trivial, but relatively
> straightforward process. I estimate it would take me 5 hours of work per
> week.
> :: Phase 2 - add Lyceum-specific features
> There are two main types of Lyceum-specific features that I would like to
> develop. The first are features which simply leverage the normalized schema
> -- template functions, hooks, utility pages, site-wide feeds... all
> accessing site-wide content in a way that is easy for template and feature
> developers to use without having to worry about complicated denormalized
> meta-tables (or any sql at all).
> The second are features which evolve Lyceum into more of a foundational
> social platform, connecting content, users, and their online publishing
> presence in an intuitive and ergonomic way.
> I could go on and on about even more things I would like to add to Lyceum --
> the main theme being seamless integration with other platforms, frameworks,
> and architectures.
> I'll stop here and let you folks respond. Here are the questions I mentioned
> above:
>
> - What value does Lyceum hold for you today?
> - Did you chose Lyceum over WordPress MU mainly because of the schema?
> - What other reasons do you have for using Lyceum?
> - In general, what do you like and dislike about Lyceum?
> Thanks for any and all feedback, and thanks for using Lyceum!
>
> John
>
> [1] http://en.wikipedia.org/wiki/Database_normalization
> [2] http://en.wikipedia.org/wiki/Shard_(database_architecture)
> _______________________________________________
> Lyceum-users mailing list
> Lyceum-users AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/lyceum-users
>
>