Lyceum-users mailing list

[John Joseph Bachir <jjb AT ibiblio.org>]

First of all, thank you for all of the encouraging things that you
wrote about the software, the project, and me. It has been a great
experience to make software that I believe is innovative and valuable.
What has made it even better is to make it for a community who
appreciate it and help to improve it by contributing ideas (and
code!).

The interesting thing about all of the feedback is that it was
overwhelmingly in support of Lyceum development continuing. It's still
a bit early in my exploration process, but I'll say right now that my
general sense is that if I can find a paying client who needs Lyceum,
I'd like to continue the project.

Bellow, I've responded to the comments and questions that have come in
so far. I'll be contacting some of you off-list, to see what projects
you are currently working on, and if you see any potential for
collaboration in the future.


On Thu, Feb 12, 2009 at 2:10 AM, Qiming Li <liqiming AT gmail.com> wrote:

> 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.

Thankfully this is the sort of thing that, if Lyceum development does
continue, will be directly and easily maintained in parallel with
WordPress.


> Another (minor) disadvantage is that, sometimes a seemingly simple
> question requires a relatively complex database query. Take the portal
> for example.... 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

The portal code is a bit embarrassingly messy. To answer your
performance question: the 5 join queries, if appropriately covered by
indexes (which they are), generally have no performance implications.


> 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"!.

All of the problems with column names are carry-overs from WordPress,
and unfortunately this will not change, even if Lyceum development
continues. However, there will hopefully be a nice offering of
functions that make it less and less necessary to do direct database
queries for popular tasks across blogs.


On Thu, Feb 12, 2009 at 8:45 AM, Bryan Thale <bryan.thale AT motorola.com> wrote:
> Our biggest technical gripe with Lyceum is that the schema
> needs to be cleaned up some and tweaked a little to improve the
> normalization.  For example, it is way too difficult to relate a post to
> a blog.

To get from a post to a blog, you do a 3 table join:
post2cat->category->blog. Depending on your need, the function
slug_from_postid($postid) might be useful to you -- definitely look at
the code in that function to see how to do the join to relate a post
to a blog.


On Thu, Feb 12, 2009 at 9:13 AM, Malaney J. Hill <malaney AT gmail.com> wrote:

> By keeping
> multiple blogs in one database, we are able to leverage cross-posting
> (posting of articles to multiple blogs), cross-searching (show me all
> blog postings containing the phrase 'foo') and cross-querying (show me
> the X most recent articles from all blogs). This simple design philosophy
> has made Lyceum the platform of choice for at least two high profile
> blogging sites that I am aware of. In both cases, the blogs are not
> entities unto themselves, but part of a larger content offering.

It's great to hear that Lyceum has been such an ideal solution for
your projects.


> DATBASE-BASED SESSIONS
> INTEGRATION WITH OTHER PLATFORMS
> ABILITY TO LEVERAGE NORMALIZED SCHEMA
> LYCEUM-SPECIFIC BACKEND ADMINISTRATION TOOLS

If Lyceum development continues and becomes a priority in my life, all
of these things will be given much more attention (and will indeed be
some of the reasons for continuing Lyceum development in the first
place).


On Thu, Feb 12, 2009 at 12:03 PM, <drivencompassion AT gmail.com> wrote:

> Maybe Automattic can hire you for WPMU - Normalized Edition?

Hmm, an intriguing idea :) I've actually pondered various flavors of
this on and off over the years. I think if I decide to continue Lyceum
development, I will get in touch with them to explore if there are
possibly points of collaboration.

> As soon as Lyceum catches up with WPMU 2.7, I will reinstall and publicize 
> many installations.
>  I'm quite intrigued with buddypress.org's extension of WPMU - John, is 
> this what your
> second described phase implements?

Yes, Buddypress has much of the spirit of what I have in mind. Of
course they are limited in some ways by the MU platform. I actually
haven't checked in on their featureset in a few months -- if anyone on
this list has experience with Buddypress, I'd be very interested in
hearing about it, on or off list.


On Thu, Feb 12, 2009 at 2:39 PM, Asheesh Laroia <asheesh AT asheesh.org> wrote:

> It's true that in WP MU generating this query is slow. But running it need
> not be painfully slow. For me, the question is how much is that efficiency
> worth in human development time to maintain *another* multi-user WordPress
> fork.

> If you abstract it away inside a function, then the backend could just as
> easily be WP MU; it would just possibly be slower than the
> non-sharded schema.

> But I wonder if it really depends on the particular database schema approach
> Lyceum has over WP MU. Maybe it can be a WP MU extension just as easily.

> When people like Brian talk about the WP MU architecture being a
> non-starter, I wonder if they've tried to run WP MU. The fact that it uses 
> so
> many tables doesn't seem to, in practice, be a real problem for anyone 
> except
> aesthetically. If you want to administer WordPress via SQL commands, it can 
> be
> difficult, but if you're willing to write even a little code it doesn't seem
> like it would be so bad. (Note that I personally haven't run WP MU, even
> though my employer has a WP MU install.)

As usual, Asheesh, one of my most loyal, helpful, and friendly users,
and I think the only one with whom I've drank (drunken? drinked.)
beer, throws down the curmudgeony Get Real and Face the Music angle
and demands accountability.

I will deliver!

I think there are two factors that you aren't quite appreciating,
because of the history of your use of Lyceum, and also the
environments in which you've developed and deployed software in
general, which have been academic institutions and non profit
organizations, where you and other project participants have been
passionate about the project.

[1] You said "It's true that in WP MU generating this query is slow.
But running it need not be painfully slow". For an installation with a
few dozen or maybe a couple hundred blogs, and/or for a query that
only runs once a minute, this might be mostly true. However, for an
installation with hundreds or thousands of blogs, and/or a query that
runs, say, every second, this is not the case at all. Let's say
someone wants to display the last 10 posts across all blogs.

:: Lyceum
select last 10 published posts from posts table


:: MU
- select list of all blogs from blog table
- for each and every blog (N), select last 10 posts from each posts table
- combine all of this data together into one array, sort the array by
date, and select the newest 10 from this array

In the MU case, both the time and space complexity of this operation
is O(N). In Lyceum it is O(log(N)). Actually, in the Lyceum case, if
you are only getting the data that is already covered by the index,
then the operation is O(10) (because the O(log(N)) work was done at
insertion-time (roughly speaking)).

Plus, in the MU case, you are going to end up doing more data
manipulation at the application layer, which incurs a cost in both
performance and development/maintainability efficiency.

The alternative is to maintain a separate table indexing all posts, at
insertion time, which is an enormous development cost.

[2] You said "When people like Brian talk about the WP MU architecture
being a non-starter, I wonder if they've tried to run WP MU." In
general, non-IT organizations with IT departments (or more
appropriately, and in Brian's case (Motorola) -- non CMS/Web
organizations who sometimes use web tools) rely on standard solutions
and best practices in order to solve problems. If a 100 person
organization (either a company, or a subdivision of a larger company)
has, say, 1 web developer, then what is expected of that developer
comes down to:

-installing standard solutions in a reliable way
-making sure that the data is easy to access and use -- in general,
make the content is as valuable/exploitable as possible
-integration with existing or future solutions

So the solutions must be installed well, and they must work with
existing tools, or other standard solutions.

NOT a typical IT request: "install a flexible blog system, give it
some cool themes and plugins, and write some nifty scripts on the side
so that people can see interesting visualizations of the community's
activity and data. Take as many hardware, services, and time resources
as you deem fit, because developing a healthy blogging community is
valuable!!"

A typical IT request: "we want team members to bloger [sic] their
Sales Stories. The system will only be accessible internally. You can
use the Linusx [sic] server we bought in 2005. If you need a database,
submit a request to Database Services. We want team members to be able
to log into their bloger [sic] using the corporate-wide [obscure EOLed
Lotus product] service [which mostly implements LDAP as the world knew
it in 1999]. You have 4 days to do this."

And THEN, a few months down the line: "the blogs are great! we want to
make a publicly accessible front-end that can search the Sales Stories
title for particular keywords, so that our customers can see what a
great experience it is to work with us. You have 1 day to do this."

By now you can probably see what I'm getting at. With limited time and
system resources, it's a big win to have a normalized database schema
that can be accessed with well-known techniques and minimal
performance or development overhead, and without having to become an
expert at working with a particular web application.

Brian-- please correct the above characterization as you see fit!

Okay-- thanks again folks for all your feedback. Let's continue this
conversation -- reply back with any and all thoughts and questions. In
a day or two I'm going to do a blog post integrating the ideas from
this email list conversation and asking for more feedback. But the
ideas from this list are definitely more relevant and important to me,
so don't be shy about chiming in.

John