MurrayAltheim2005Q2

(this is the archive of discussion on MurrayAltheim’s page 2005 Q1-Q2)


It’s good to see you again. I know we’ve quarreled in the past, but I honestly like you, and appreciate what you’re doing for every one of us. :)

Hey Lion. You know, I don’t think much about any quarrels, mostly about a very enthusiastic and energetic person who is also trying to do right. I always enjoyed our discussions, even when we disagreed. I don’t require the people around me to agree with me, and in fact think it’s probably better when that’s not the case – look at the Bush administration as an example of lack of diversity of opinion. I’ve not been gone because of any anger, just overwhelmed by my Ph.D. studies, and for the past month or so the bookmark I had for the wiki site no longer worked. At some point things will slack off enough that I can spend more time involved in things beyond this exercise in my patience…

:)

I don’t know if you have time for this, but, re: APT, you may be interested in what I’m calling "GTF", or "General Text Filter." See also "The General Text Filter Strategy."

It’s a protocol for calling text filter services over the Internet.

http://ln.taoriver.net/img/gtf.png

So, someone could just plug in the URL for an APT text filter, and start using APT. Don’t have to install anything on their machine, beyond the basic GTF interface.

You could even make it work in pipes on the command line.

cat myfile.txt | gtf http://www.altheim.com/apt/service/ > myfile.html

You just make an XML-RPC web service that meets the API, and transforms APT to HTML. Then anyone with the tool on the command line, or in their blog rendering pipeline, or their wiki rendering pipeline, or whatever, could make use of it.

I personally intend to promote it, in order to promote Local Names. But Local Names is just one small filtration thingie. There are many filtering agents people want to use.

You could also create reverse “HTML-to-wiki-syntax” filters meeting the same API.

Enough about that.

Good to see you!

Lion, the GTF seems like a cool idea, a basic “web service,” but the first thing that came to mind was the potential for security problems. I guess you’d only use a filter service from someone you somehow trust.

So if I understand this correctly, since Ceryle can function in command line mode as an APT-to-XHTML converter, if I had someone post a copy of Ceryle on a server with a perl or python or shell script to feed it people’s documents, it would return the result to them via HTTP. And of course that could act as a pipe. Since Radeox is currently built into Ceryle, it would potentially be possible to have the same “engine” do the wiki-to-HTML service. I’m not sure how you’d do an HTML-to-wiki service though, since it’s a lossy conversion. But if that isn’t an issue, sure. Cool.

I’m about to read up on the names you mention but I don’t know, but in case I get lost in link-land:

Okay! So we don’t even need XML-RPC; Just POST the content in, and use http://foobar/index.cgi?arg=val&arg=val&arg=val …, and the response is the replacement text.

Sorry Alex; But, I actually meant POST.

I have difficulty imagining feeding in an entire wiki page as a parameter to a GET request.

Usually POST is used to feed in a big fat blob of text, right?

(Incidentally, it really scares me, the idea of people changing what I said… Because it’s really convincing looking, with my face there and all…)

Well, in a GET request, you pass the parameters as part of the URL. So http://foobar/index.cgi?arg=val&arg=val&arg=val is GET. In a POST request, you pass the parameters as the HTTP request body. In a GET request, the body is empty. In either situation, you get back a result which can be rather big. You’re supposed to use POST if you are updating data on a server, but practically you only need to use POST if you’re sending large blobs of data to a server (or if you want to avoid the parameters showing up in log files, since URLs are usually logged and request bodies are not).

Yeah, I get you.

Something in me wants to put the little arguments in the URL, and the big arguments in the POST body, but I suppose you are right.

:)

As a programmer, I have no problem with POST vs. GET – on the CGI side it all looks the same to me. From a usability point of view, putting all arguments in the URL can be interesting (eg. for search URLs), but putting only some arguments there is no good. :)

Languages: