Talk:TingWiki/ting17
From S23Wiki
[edit] ting17, sunday 10th of April 2005, 18:00 UTC (20:00 CEST)
ting17_talk
See also ting17_document on the article page.
Page from moon-edit, server: is-root.de, port: 32123,
[edit] ting17_talk moon-edit page inclusion
ting17_talk
----
Participants
* ma: Mattis Manzel
* lk: Lion Kimbro
* F: Fabi alias MoinMoin:FlorianFesti
* ...
----
F: Topis still is InterWiki (see ting16_talk)
Ok, subtopic: InterWiki <-> WikiNameService <-> LocalNames
I am not 100% sure if I understood everything about LocalNames.
Per default LocalNames works with explicit Names not as InterWiki which allows to concatenate the Pagename to the wiki url. Right? IIRC this can be done by FINAL terms.
So this boils down to: How does the interwiki map look as LocalName service?
lk: In Local Names, you can say:
PATTERN "otherwiki" "http://example.com/wiki/$NAME"
lk: That would mean: "There's another namespace called 'otherwiki,' you just put the page name after 'http://example.com/wiki/'.
lk: But if it has a full namespace description, you just:
NS "otherwiki" "http://example.com/wiki/namespace.txt"
F: Which contains pages -> page URLs
lk: Basically, yes. (Other stuff too, but that's mainly it.)
LN "foo" "http://example.com/bar"
F: Are relative URLs allowed as LocalNames?
lk: Sadly, no: Not this time around. The closest thing to relative URLs are PATTERN lines (like you saw above,) and "X FINAL" - last resort pattern to apply when resolving a name, and not knowing what to do with it.
F: So a wiki NS would contain lots of redundant URL prefixes.
lk: Yes, if you were to list pages without using X FINAL:
X FINAL http://thiswiki.example.com/wiki/$NAME
lk: That means, "If someone's looking for a name here, and it's not found, use this pattern."
F: But using FINAL does give away the advantage of having a page list.
lk: Yep. The older Local Names format actually had what you want- you could say, "Here's a list of names, use this prefix for them." However, I made a decision to toss that, because it complicated the parser a lot. I decided to just list out all the pages, because it was simpler, and not difficult to just list all the pages with full URLs.
F: ok, lets disscuss this technical details later. It's just an optimization.
LK: Yeah, I'm mainly concerned with adoption at this point. In 2006, I have on the schedule to write a MoinMoin parser that resolves via Local Names. If there is interest, of course, I can bump that forward. I don't want to miss any boats.
LK: It's useful to note, I believe, that you get NearLinks, the ability to use wiki names (as in NearLink use, as well as full InterLink) via
F: Ok right now LocalNames can only link to URLs. So it's not possible to link to aggregated values.
LK: "aggregated values?"
F: See ting16 line 11++. I'd like to ahve more information about the wikis than an URL.
LK: Ah: You can do all that, with Local Names meta-data support. Indeed- some of it is already there. For example, there is:
X PREFERRED-NAME "Foo Bar"
LK: You can even see support for it right now:
http://services.taoriver.net:9090/?action=cached
LK: It wil tell you the names of the namespaces that are presently cached.
LK: You could easily extend it to say:
X WIKIENGINE "MoinMoin vwhatever"
LK: Though, I am personally of the opinion that that sort of specific data should come through something other than the naming system. (That is, I think there should be a wiki metadata format, for relaying that kind of information.)
LK: Am I addresing "aggregated values?"
F: Yes, but I am not shure how this relates to LocalNames. If I have a wikimetadata server I can get the URLs of the wiki from that.
LK: There are a lot of ways to get URLs for a wiki. Local Names is a system for collecting and coordinating namespace information in particular, for use across a broad number of systems (blogs, email, IRC logs, wiki, ...)
LK: It would be a major win for a lot of reasons if Local Names were supported in wiki. Not just for Local Names, but, I think, for the whole of Internet communications systems: Blogs and wiki would transparently link to each other, and people would think about their communication tools in a - back
F: OK, lets sketch such a Wiki Name Service (WNS) system in the terms of LocalNames!
LK: Okay! {:)}=
F: There would be several NS that match INterWiki names to URLs. Each wiki could deside which of them it loads into it's local scope.There could be a meta NS that links to all those NSs.
LK: Yes! (We already have a MoinMoin & WikiXmlRpcInterface wrapper, incidentally.) Yes, that's exactly it.
F: to get additional information about wikis there would be a different NS that matches the same InterWiki names to the wiki descriptions.
LK: Check out:
http://wrap.localnames.taoriver.net/
http://wrap.localnames.taoriver.net/spaces/
LK: Yes, you could do that as well, or, you could gather the metadata about the wiki into that particular wiki's namespace description. Although,...
LK: I'm of the mind that metadata support in wiki is so critically important, that it should be a seperate thing. Mutante and I wrote up an idea; I'd like to show it (and supporting code) to you at some point. There's a lot of things we need to do with it, but, I want to know what you think.
LK: This isn't to detract from the presnt naming-system conversation, though.
F: We could also use a X WIKIINFO statement to link to this information. Right now I think that namespaces per wiki are a bad idea because this requires cooperation with the wikis itself. I would prefere a system in which the wiki do not have to know about the WNS. That way it would work with (more or less) all wikis and is much easier to be applied.
LK: EXACTLY! Yes! (re: X WIKIINFO)
LK: Although, you don't need the wiki's to know, because we have a wrapper. If a wiki supports plain-text listings of pages, OR the XML-RPC wiki interface, then we (already) have a wrapper that generates a namespace description for that wiki. (We could add other scraping methods, if needed.)
LK: I also want to point out: You can *sort of* kludge in use of the Local Names infrastructure within any wiki that supports InterLinks, as they presently stand-- What you do is link an InterLink name (lets call it "LocalNames" for now,) and then bind it to a link redirection. For example:
localnames http://services.taoriver.net:9090/?action=redirect&namespace=http://example.com/mynamespaces.txt&separator=:&lookup=
F: I don't know if this is a good idea. I alread have headaches about these large Namespace files that have to be transfered. Even if some caching is allplied to this.
LK: I'm sorry, I'm not understanding the perceived deficiency. The namespace server performs all caching, it timeouts individual namespaces x1 / week (by my immediate configuration.)
F: If I use the wiki namespaces as page list and use them to render the interwiki link the way we do it with local links these list have to be up2date. Much more uptodate than once a week.
LK: Yes, yes, and there is support for this: There is an explicit "dump-cache" command as part of the Local Names Server interface standard.
LK: Now, at present, there is no speficied way to register as an observer. So, you have to do that outside of the interface description. However, that'll be added, and,..
F: Ok, I guess it is time to describe something completely different:
I wrote an (prototype) of an RecentChanges server. It allows/supports:
* polling of RSS feeds and wikirpc RecentChanges
* subscription to regular expressions (RE) of pagenames
* notification if on of these REs match
* a filtered RecentChanges list accourding to the subscription REs
* notification of the server that there just was an edit
It is intended to be used as implementation of MoinMoin:AdoptedPages which allows to add the RecentChanges of single remote wiki pages the the Recentchanges of the own wiki.
This Wiki Name Service would make the implementation of this server much easier, as I would need all this information anyway.
Main problem is thta most RSS feed and the xmlrpc interface do only offer very limited information about the single edit. There are no diff, info, ... links provided. To have a really good integration of this feature in the local RecentChanges this information is needed and can be easily calculated with some knowledge about the remote wiki engine.
LK: let's see, that's a lot at once- I'm feeling, right now, that we should go a level up, and look down.
F: Ok, what do you see?
LK: I'm looking at:
* General metadata needs,
* linking systems
* notification systems
* update distribution
* page change distribution
LK: Anything else major missing, in the scope of what we're talking about right now? This is the picture as I see it, right now.
F: The problem is that update distribution and page change distribution may be connected if you use the "page list kind" of name spaces.
If you use the page list to generate the wiki name spaces these name spaces change (have to be changed) when the pages change. So you have to monitor the wikis for new/deleted pages.
(Moin mattis!)
This is not that trivial, especially if you don't have support form the wikis and want to keep the polling traffic in sensible borders.
LK: I'm not sure I totally understand. I once had an RSS-feed observer. It would observe an RSS feed, and send a signal whenever there was an update. (That is, the monitoring does not seem like a big obstacle to me.)
F: How does this observing work? I don't know too much about RSS.
LK: Ah, okay: Well, when you started the program, you would give it three pieces of information:
* the RSS feed to scan
* the period with which to scan ("every 15 minutes") or ("every 5 minutes")
* the URL of the XML-RPC interface to receive the change signal
LK: So, you just pointed it at a wiki, and you had, with 15-5 minutes resolution, notice of new changes.
F: so this is traditionally called polling.
LK: Yes, that's right. That's exactly what this is. That's what you HAVE to use, when the wiki doesn't have an observer registration or event system in it.
F: which most wiki don't.
LK: Exactly. When MoinMoin includes an event system, thing's'll be different. Maybe Jabber based or something. The internal system is all we really care about; plugins can attach to any outside system from there.
F: Ok, so you do polling to all the wikis you observe. And all wikis using your service are polling your server.
LK: Hm,... Not quite right-
* "my server": hopefully they are runnig their own instance, though it's okay for them to use my personal server should they like
* "polling": They only pull when they need to perform new bindings. That is, when a user makes use of names from outside the immediate wiki.
Finally, I would like to add:
* on ComunityWiki, we NearLink Meatball wiki. The names are updated only x1 / day. This is only very rarely a problem.
* (so, we don't *have to* poll x5 minutes, though I'm fine with doing so, if the RSS feed isn't too large.)
F: The problem I see is: every wiki polls every other wiki (it knows of)(may be only the once it links to). The goal of this all is to make the wiki know more wikis than they know today. This leads to a kind of quadratic polling.
LK: How so?
LK: Really, I'm not seeing it.
LK: Where is the excess polling? I see only one poll per wiki. Maybe two.
F: We said there is a name space mapping the interwiki names to the name spaces of the wikis. This is used by all wikis. If the wiki link to another they need to get this namespace. SO you have x wikis you link to you have to get x name spaces. The alternative would be to just use one name space as we do in the interwikimap today.
LK: People will use the name servers more and more as this goes on, and the name servers will be the ones-
LK: No, not even- because you're sharing name servers.
LK: I'm feeling a little offended, because you're not understanding this system, and you're angry about things that aren't there.
F: sorry, That wasn't my intend.
LK: For the 5-minute resolution stuff, I was talking about aggregating RSS feeds to make super feeds, and running namespace updates off of that. (First,.)
ma: yes, peace brothers, peace :)
LK: For namespaces, you only need to update *when names are used.* That is, you don't need a pull even x1/day. It's like:
LK: MoinMoin wiki- they only pull BadContent *when it's needed.* Not regularly; Not every hour.
ma: export to wiki doesn't work yet. :(
F: Ok, let's assume this is no problem. (May be I do some maths about it later)
Let's talk about something different: What do we already have and what would be still need?
LK: For what things?
LK: (also, I'm more interested in talking about that high level map-)
LK: Do you mean for Local Names? (what is currently in posesion,..)
F: For using LocalNames as local interwiki map replacement.
LK: We presently have pretty much everything that is necessary to do it on a primitive level.
LK: I mean, we use it on the TaoRiver wiki, though, because I haven't updated my Intermap since the upgrades, it's not in the new version. As I was saying-- You can use the Local Names system by binding an InterLink name to a redirect URL.
F: Right now we ship 90-100 wikinames.
LK: I guess all you need is a namespace description for your grand registry of wiki.
F: For getting the page list it would be of value to know the wiki engine that serve the different wikis. So additional meta information per wiki should even be ready first.
LK: Yes, that would make using the wrapper a lot easier.
LK: I'm not sure I totaly understand what you have in m
