It's Like Déjà Vu All Over Again
"You could probably waste an entire day on the preceding links alone. But why take chances? We also give you Paul Snively..." — John Wiseman, lemonodor
TclKit is cool, but given the application, how about Mozilla as a front end?
Well, hrm. It's hard to know how to answer this. TclKit and Mozilla don't really have much in common.
XML-RPC blogging is already in baked in... as is XML parsing and lots of the niceties that tckKit offers, including running on Mac/Win/*Nix.
But what I'm proposing is implementing a very different set of data structures, algorithms, and protocols from what are used right now: basically, take the really "raw" materials from Nelson's work and try to get as much leverage on certain hard parts, e.g. flexible-but-reliable persistent storage, from tools like TclKit as possible. TclKit strikes me as a good starting point because it covers three important areas (GUI, scripting, and persistence) extremely well, portably, and without forcing the developer using it to make many ontological commitments. In particular, it doesn't presume that what you really want to do is write another web browser.
Again, if the goal were to experiment with existing web infrastructure, I'd almost certainly start with Mozilla (or at least Gecko). But that's not the goal. On the contrary; the suggestion was to start with a very small handful of extremely high leverage, loosely-coupled tools and see how quickly/easily we could prototype critical aspects of Nelson's Xanadu concepts. My perception is that tools that offer integration into existing web infrastructure would actually impede progress rather than aid it.
9:07:24 PM
David McCusker replied to something I wrote days ago. For some reason, I haven't seen anything from the RSS scrape of his site for days. Hmmm. So I'm reconstituting this by hand. Here we go, piece by piece.
I'll start a response by asking questions. I hope I'm not too negative.
Hardly. One of the aspects of even suggesting such an endeavor that I look forward to most is precisely this kind of discussion and refinement of concepts. If it leads to software artifacts, great; if not, at least we'll have tossed the conceptual football around and hopefully have learned something from that.
Paul Snively:
Hmmm. David McCusker has expressed his
willingness
to hack Scheme with me. David and
Raph Levien have
indicated a strong desire to collaborate. Raph (mind if I call
you "Raph?") has designed and implemented one of only two
demonstrably attack-resistent trust metrics in the world.
I hereby propose that David McCusker, Raph Levien, and I tackle
Sam's idea: a weblog/RSS feed collaborative filtering system.
I'd consider it, but it seems awfully high level application
heavy when I favor writing libraries of low level mechanisms. I could
write tools for something like that, but to really get engaged in an
app development would require special interest. The RSS feed problem
hasn't drawn me yet at all, even to the extent wanting the product.
I agree wholeheartedly. One of the reasons that I proposed developing in Scheme, apart from your recent comment that you'd work with me in Scheme and the observation that Scheme is an excellent exploratory language, is that I find that it lends itself to precisely the kind of functional decomposition that you describe: you essentially develop an API to address the domain. You may or may not develop a domain-specific language to implement/support the API and/or develop the app in. Then you do (or don't) develop the app.
Also, as a matter of personal style, I tend to program that way anyway (that is, as if everything were an API development project, and any applications to be built on top were there as much to validate the API as anything else). I suspect that this is partially because Lisp-family languages were among my first; partially also due to early exposure to object-oriented design principles that effectively demand this view, such as Model-View-Controller; and partially due to hard-won experience with AppleEvents and AppleScript that also mandated rigorous separation of human interface from "engine."
So I would very much expect the principal artifacts of any such project to be a set of libraries. They might not be in Scheme, either; we might use Schlep to transliterate them to C. Or we might prototype in Scheme but then ossify in C++. Whatever. And then it'd be nice to give an app to folks who want one.
However, the definition of the exact problem would be interesting, and
it might be fun to sketch out implementation related definitions that
aim to solve whatever problems appear to be involved. That could lead
to more interest in actual coding, and the discussion of the problem
itself might inspire other folks, and make us think of more ideas.
To my mind, that's exactly the expected benefit: you're smart, Raph's smart, I'm smart. What would happen if we were to tackle a project like "TiVo for Weblogs" as if we were going to implement it?
I'd be remiss if I didn't point out that a lot of useful infrastructure is already being put into place, with the mad rush to automate things like backlinking and RSS discovery. It seems like we could tap into some of that infrastructure in order to build something that would actually work. But obviously there's a huge amount of definition that needs to be done before we could even contemplate such a thing.
The first questions involve what is supposed to happen? What's the
desired result, and how should things be organized? It sounds like it
ought to be a protocol of some kind, which different server implementations
might satisfy. (This is keeping Raph's interfaces opppositions in mind,
where other choices are file formats and code APIs.) [David McCusker]
Quite right. If you haven't already done so, please read Sam Ruby's "Beyond Backlinks" story and go to the end for the one-paragraph version of "what should happen." So to begin to bring this back to the "libraries vs. app" question, does it sound like it would be fun to develop a library for doing relevance ranking on text, HTML, RSS...? And then, maybe, to build an app on top of it? Maybe a better question would be: given Sam's goal description, what interesting library development opportunities, if any, do you see?
8:15:59 PM
