FrontPage SiteMap RecentChanges HowTo Blog

Matching Pages:

RSS

Saudi Arabia, National Day

GroupServer

A GroupServer is a channel (TheChannel) that uses more than one technology (TheMedium) to get the benefits of each (MediumAttributes).

Another name might be – you guessed it – GroupWare.

Discussion

So, if I were going to put together a GroupServer in 2004, I'd include:

  • Some kind of WikiEngine, for building the group's Web presence
  • Some kind of WebLog interface, with comments, for building individual Web presence. (Wiki diehards may respond that a WikiEngine plus some BehavioralNorms could do this, too).
  • MailingList software for asynchronous message-based communication. (Alternate short-list: UseNet, WebForum?.)
  • Jabber server (or IRC server) for synchronous message-based communication.
  • Personal profile pages, with FriendLinks? between profiles, a la social networking Web sites. Profiles publishable to the public through FOAF, of course.
  • RdfSiteSummary? for at least the Wiki, blog, and possibly the mailing list stuff.
  • All the authentication and such held together by an LDAP directory. Possibly profile info in there, too.

Some things I'd leave out:

  • Group calendaring. I just never use it.

Anyways, I wonder how close Gforge or some such monster would work here.

I also wonder how hard it would be to let the little GroupServer clusters interoperate. Obviously, Web access makes the Wiki and WebLog stuff work fine. Jabber operates across boundaries quite nicely. Profiles and social networking interop with FOAF. And LDAP authentication interops nicely everywhere.

Fun stuff to think about.

PeriPeri does 'blogs and mail-archiving, mostly. You'll have to wait a little for FOAF, though.

Well, hang on a moment- my concept (at least) of the group server is as a meeting place of mediums. But not those mediums itself.

It's the difference between a gigantic monolithic app, and a ton of little apps.

If you make the GroupServer into something that is one gigantic thing that strives to include all technologies, then you have several limitations:

  • When people make new technologies, you cannot use them.
  • When people want to change something in the GroupServer, they have to work through the developers' organization.

OneBigSoup isn't meant to be "one gigantic monolithic web app"- rather, it's meant to be the smooth flow between the hoards of little apps out there.

We already see it in development, because we're seeing things like RSS and URLs and other things made to attach fragments.

We'll have templating protocols, and transclusions, and document interchang, and event subscriptions, and those kinds of things, in the OneBigSoup future.

But monolithic apps are sort of out.

I'm thinking: What we really need on the web are more protocols, not necessarily more apps. I mean, there are more apps we need- like the GroupServer, and the log server, and the event server, and stuff like that.

But protocols are our current focus, I think.

So, what this means in terms of the spec above:

  • The GroupServer interprets and presents the RSS feeds from the wiki that the group uses. The group can use any wiki, or collections of wikis.
  • The GroupServer interprets and presents the RSS feeds of the blogs that the group members use. Individuals can use generic blogs from a blog server, or they can hand-make their own blog, or use whatever other blog technologies that they care to.
  • The GroupServer can read and use ThreadsML (or RSS, or whatever) to observe and present mailing list traffic. If people use IntComm:TransparentEmail (I think I wrote that up…), and they are members of the group, and mark the email as something the group would be interested in, it shows that too.
  • The GroupServer can plug in to IntComm:EventSystems?, and show relevant events that people are interested in.
  • The GroupServer has a maleable structure, so you can link to your personal profile pages in there. Of course, the GroupServer could interpret FOAF information as well. The key word for the GroupServer is Computer-Multi-Lingual. It speaks as many protocols as possible.
  • (Sadly, I don't know what an RdfSiteSummary? is, or an LDAP directory.)
  • If you wanted to use calendaring, by whatever calendaring protocols or web utilities there are, you could. If not, just don't link it in, by the power of our (yet to be made) protocols.
  • It's not hard to make these things interoperate, because it's all protocol based.

Important things that you missed: LocalNames services, so you can use names of pages in your wiki in your mailing lists, and names of threads in mailing lists in your wiki pages, and so you can name a FOAF file with just "LionKimbroFoaf?" and have it resolve to wherever your FOAF comes from, etc., etc., etc.,.

The GroupServer would have a "front page," of sorts, that aggregates everything that people think is cool. If you saw something on one of the lists that you thought everyone should see, you can "promote" it to the front list. Say you thought one of the RSS entries on the blog page was particularly relevant. You could promote it to the front page. You could write directly into the front page list- sort of like an IRC comment. You could also throw stuff off of the front page list. (This all assumes that you are a trusted group member.)

If you posted on some wiki that wasn't part of the wiki that the group usually watches, it doesn't matter. Just manually add to the RecentChanges list that you wrote on such and such wiki, with a relevant comment, and people can see it.

RdfSiteSummary? == RealSimpleSyndication? == RSS. I was just trying to expand an acronym into a WikiWord.

LDAP is the LightweightDirectoryAccessProtocol?. An LdapServer? is more or less an object database server. They're usually used for single sign-on solutions. Different applications use the same LDAP server for authenticating users. So, say, I would use the same login for my Jabber account as I'd use to manage Mailman subscriptions. You can think of an LDAP server as an "identity server" or a "user profile server". LDAP can handle more than just user profiles, but that's what it's primarily used for in 2004.

There are a lot of LDAP implementations, and there's an LDAP interface to Microsoft's [= ActiveDirectory? =] server. Probably the most-used LDAP server is OpenLDAP.

The only reason I'd recommend LDAP is that it's well-implemented as a secondary authentication system for a lot of applications, so it'd make equating identities in multiple applications relatively painless.

I've just been researching OpenLDAP and Wikipedia:Directory_service. I still don't get it.

It seems to me something like a secured Windows registry. It has directories, and there are key-value pairs in the directories, and you can secure access to the directories and key-value pairs. You could say, "Let Joe look at this, but not Fred."

Is that right?

What else does it let you do?

I've been thinking that the PersonaServer is where you change your personal things, like your FOAF file, and stuff like that.

The GroupServer is more where you would interact with other people. The GroupServer would point to each individual's PersonaServer.

I saw something somewhere saying that LDAP directories could do something like URL redirection. I was wondering, "Perhaps we could do a LocalNameServer? by using an LDAP server?"

That's technically what an LDAP server does. But de facto they're mainly used as a central authentication database, though. So if you have multiple applications that need logins, for example, people can login with the same password everywhere, and their settings are saved in one place.

There are, say, Apache auth backends for LDAP, Jabber auth and profile backends, Linux login using LDAP. A number of email clients use LDAP for a shared addressbook style thingy, too.

The point: an LDAP server stores user accounts and profiles, and performs authentication. You can store other kinds of info in an LDAP server, but that's what people mostly do it for.

How does it authenticate you?

For example, say you point your web browser at my wiki. How does my wiki talk with you and the LDAP server to assure that you are you?

Your wiki engine has to support LDAP, either by leaning on the Web server's authentication services, or on its own. There are LDAP libs for Perl, Python, and PHP, as well as for other languages.

The wiki engine could have a form for logging in, with username and password. It then passes this info to the LDAP server, and the server either accepts or refuses it. Badda-bing, badda-boom!

By the way, I get what you're saying about the difference between a PersonaServer and a GroupServer. I think an LDAP server would make a nice PersonaServer.

Oh. ;) I was hoping you didn't have to login at all.

I was wondering how that trick was pulled off. ;)

We need some sort of communication between the web browser itself, and the authenticator.

There are, in fact, ways to do that. It's a hairy problem, though. SAML is one that comes to mind immediately; client-side SSL certificates are another. Microsoft Passport is a third. Even when you have this going, though, you'll have other client programs (instant messenger, email client) that don't use the browser.

random feature request: also, allow the admin to choose to do authentication through their webserver (.htaccess and all that) rather than through your system.

By the way, I think you originally started out talking about the RecentChanges functionality of the GroupServer. I think this is mostly separable from the LocalNames part (from a programming point of view). We should write it as a generic FeedSplicing/rating/editing library for RSS feeds which is then included in a framework for reading/writing/combining the RSS feeds for the various group applications, which is then one component of the whole GroupServer framework.

VirianFlux? pointed this out to me: http://www.netvibes.com/

It's so close!

Lion:

I only had a few moments to spare, but I really liked what I saw. Which is why I am curious about why you think its ONLY "so close". What other features are you looking for?

Isn't it great?

Here are some of the things I think we need, though:

  • OpenSource (as always)
  • permissions & wiki-like versioning of "edits"
  • WikiAndIrc-like window into activity on an IRC channel
  • styling (of both the page template, and individual RSS feed presentations)

How did I come up with that list? I asked myself: "What would it take for this to replace the RecentChanges page on this wiki?"

Tried it too, pretty cool! Feeds from here and from oddwiki all integrate fine. Mediawikis are different, some, s23-wiki, 22C3-wiki do not validate, others, Berlin-wiki, Podcast-wiki work. It also integrates writely documents, yeah. Move the prize watch down and enter "lenkbares Luftschiff", then it doesn't annoy you with anything ;).

I think what lion meant is, that it is so close, not open, it is for your private watching only and you can not make the page readable to the public. Or do I mistake on that?


CategoryGroupWare

CategoryOneBigSoup?

Define external redirect: RdfSiteSummary LocalNameServer LionKimbroFoaf ActiveDirectory RealSimpleSyndication WebForum FriendLinks EventSystems CategoryOneBigSoup VirianFlux LightweightDirectoryAccessProtocol LdapServer

EditNearLinks: BehavioralNorms PeriPeri ThreadsML GroupWare WebLog MailingList WikiWord UseNet WikiEngine OpenSource

Languages: