Multiple Blog?
Khaled Abou Alfa
know what the outcome was (I guess a lot of IRC stuff went on). So is
habari going to force me to install something new every single time I
want a new blog (thus adding to the login passwords and stuff I already
have, i have to maintain at least 7 blogs and I'm sure others have 5
times as many) or can you I log into one place and have multiple blogs
looking at different urls? So as maintenance can be down to one single
install? (My preference should be clear, however how you'd go about it
and why this hasn't happened in WP makes me assume that it's not as easy
as pie sonny jim).
This is just to keep in mind when we're building the UI is all.
Scott Merrill
> So is
> habari going to force me to install something new every single time I
> want a new blog (thus adding to the login passwords and stuff I already
> have, i have to maintain at least 7 blogs and I'm sure others have 5
> times as many) or can you I log into one place and have multiple blogs
> looking at different urls? So as maintenance can be down to one single
> install?
I like the idea of "multi-blog", but I think a little more examination
of the issue is in order.
You currently have 7 discrete blogs, each with their own usernames and
passwords. I presume each of these is at a different URL?
If these 7 blogs could be synthesized into a single Habari installation:
* How, in you mind, would you select which blog to post to when creating
a new entry?
* How should Habari determine which blog to use to service the current
request from a visitor? URL only? Some other mechanism?
* How might you integrate content from one "instance" of this Habari
multi-blog into other "instances"? That is, how might you get a photo
from your photoblog to display on your journal?
* How should Habari handle theme files? Presumably each instance would
use its own theme?
* Should user accounts cross all 7 blogs?
This last bit might get a bit tricky: we use cookies to store some user
data; and per the spec cookies should only be set for the domain on
which they'll be used. So if you log in to site1.com, the cookies there
should be not visible to site2.com, which means users would need to log
in again.
These -- and more -- will need to be addressed in any multi-blog
implementation. The more we can think about it, the more likely we are
to develop a workable solution.
--
ski...@skippy.net | http://skippy.net/
gpg --keyserver pgp.mit.edu --recv-keys 9CFA4B35
506C F8BB 17AE 8A05 0B49 3544 476A 7DEC 9CFA 4B35
Chris J. Davis
client (Atom Publishing Protocol). This would allow you to have your
7 different sites, but manage them all from one interface.
Just something to keep in mind.
Chris
khaled Abou Alfa
Khaled Abou Alfa wrote:
> So is
> habari going to force me to install something new every single time I
> want a new blog (thus adding to the login passwords and stuff I already
> have, i have to maintain at least 7 blogs and I'm sure others have 5
> times as many) or can you I log into one place and have multiple blogs
> looking at different urls? So as maintenance can be down to one single
> install?
I like the idea of "multi-blog", but I think a little more examination
of the issue is in order.
You currently have 7 discrete blogs, each with their own usernames and
passwords. I presume each of these is at a different URL?
Yup, each one with a different URL.
If these 7 blogs could be synthesized into a single Habari installation:
* How, in you mind, would you select which blog to post to when creating
a new entry?
One idea could be that when you log in, you also have a third option to choose/change which blog it is you are logging into. Maybe one of the admin options could be to set one as default? This increases the number of fields you've got to fill out to log in which might be a pain. Anyone have any other ideas?
* How should Habari determine which blog to use to service the current
request from a visitor? URL only? Some other mechanism?
* How might you integrate content from one "instance" of this Habari
multi-blog into other "instances"? That is, how might you get a photo
from your photoblog to display on your journal?
Ah well this is an interesting question. I've actually started writing a few more details for the design manifesto which should ideally bring these ideas out as well. It's all down to what the actual user NEEDS to see as the bare essentials in order to start publishing. One of those things would be a media uploader. I should be sending this through later on this evening.
* How should Habari handle theme files? Presumably each instance would
use its own theme?
Yeah I'd imagine that would be the case.
* Should user accounts cross all 7 blogs?
Well I guess this is all dependant on the actual user levels that we'd like to establish. ie above a certain level you get to see all associated blogs on this particular install. Anything below and it's all down to this one and only blog that you've got permessions to.
Yeah I can see what you mean here. I guess once we've established the means by which we log into a sepecific blog then some of these issues might get addressed as well.
khaled Abou Alfa
Owen Winkler
> Could you elaborate a little bit further, no ideas what APP is all about but
> it sounds promising though :).
Atom Publishing Protocol is a way that you can use standard HTTP verbs
and authentication to extract and update content on a site.
Basically, you have an Atom feed. In addition to the common use of
syndication, if you are correctly authenticated to the server, the
Atom feed can include additional information about your posts that are
useful from an administrative point of view. For example, in addition
to the content that post contains, details about whether that post
accepts comments might also be one of the elements published in the
Atom feed.
Note that this "special" Atom feed is only available to users who log
in using their site username and password.
Certain clients (like Ecto and MarsEdit) can authenticate you to the
feed, read this additional data, and present it in an interface for
you to edit. When you have completed your editing, the client
application uses the HTTP PUT verb to send that feed in the same
format back to the server. The server accepts the incoming data,
parses it, and writes it into the appropriate place in the database,
effectively altering the posts themselves.
Ecto is a desktop-based APP client (that's not very good). It
requires that you execute it on your computer. Habari's admin could
be a web-based APP client.
What Habari's admin would do is present a pretty interface to you
through the web browser. It would send requests for Atom feeds from
the Habari instance on the admin server to the Habari instance (or
some other Atom-enabled blog software!) on the publication server.
Note that the admin server and publication server could be the same
domain, same box, or different domain, different box.
The key facet is that the admin is completely divorced from the
publisher, and you'd be able to hook the admin to any publisher that
supported APP. So in essence, you'd be able to control more than one
blog from one admin interface.
I hope that wasn't as confusing as it sounded on a subsequent read.
Owen
Trevor Turk
Owen Winkler
>
> Is the admin area an APP client, then? This sounds totally awesome!
The admin aread isn't currently an APP client. That's phase 2 of the
plan to rule the world.
First, we need an APP server to control that we know works correctly.
There are a lot of features that the admin does that are not strictly
post-related. Comment moderation, user maintenence, plugin
activation... Lots to think about yet.
But ultimately, yes, this would be an excellent path to tread.
Owen
Broken Kode
Trevor Turk
> What's APP?
Owen talked about it earlier in this thread. Here's a link to the post:
http://groups.google.com/group/habari-dev/msg/35a1491c84a17f05