[Prev][Next][Index][Thread]

Exporting Concordia Sage Files

At 9:40 AM 9/14/95, Pete Halverson wrote:
>I'm hacking together a simple Concordia->HTML translator, and I'd like to
>link this into our CL-HTTP server by exporting URL's that look something
>like
>
>    http://host/sage/type/topic
>
>e.g.
>
>   http://scorpius.galaxy.mystech.com/sage/section/Network_Addressing
>
>However, I'm still somewhat vague on the way EXPORT-URL works, particularly
>how it maps incoming URL requests to export definitions (and thence to
>appropriate handlers).

It appends the host-name and scheme to teh requested URL and then hashes on the
string to get the object. Thereafter it does multimethod dispatches.

 My initial model was that an entry that looked like
>
>   (http:export-url #u"/sage/" :html-computed
>                    :response-function 'translate-sage-topic)

Your response function is going to be called on url and stream wheren
url  is an interned url. You can extract the components from the url object and
reassemable a pathname.

Try turning on debugging with debug-server to get your hands on the data
structures.

You would have to export one of these computed URLs for each concordia
pathname, which
might be a pain.
>
>would cause any URL's beginning with "/sage/" to be passed to
>TRANSLATE-SAGE-TOPIC, which could then destructure the components of the
>URL to find the corresponding Concordia topic.   However, there doesn't
>seem to be an obvious way to make this work -- I get various "no applicable
>method" errors.  Naive attempts to use pathname-like wildcards
>(#u"/sage/*/*.html") failed as well.

CL-HTTP doesn't do anything special with wildcard like * at this time.
They aren't in the http spec.

>
>Is this doable, or am I way off base?  I know I could probably use a search
>URL instead ("/sage?type:topic" or such), but I'd prefer to stick with a
>more structured URL list if possible.

* Using search would do what you want. You could put the service on a special
port and hack the server to append the search stuff to all incoming urls.  See
the function provide-service.

* Another approach would be to define a recursive directory export-type for
sage files. This would return translated forms of the sage resources (HTML).
It could use content negotiation to decide which format to give a client
(see the
next http spec).  Users ask for file.sage and they get back file.html

        o You will need to create an export type for a single sage file
that does what you
        want.

        o  Then, you should be able to just define a directory export type
for that export type.
        See the export code near the end of http:server;server.lisp

I can see dynamic translation of the sage files having a number of
benefits, but would it be
possible or make sense to cache out an html version, perhaps with
associated imagery?

Hope this helps.
Follow-Ups: