Loading ...
Sorry, an error occurred while loading the content.

Case Study (was Re: REST & User Interfaces)

Expand Messages
  • Seairth Jacobs
    Okay... here s a test case I am currently working on (RNA). Tell me if this looks good or not: Key: {id} would be something like seairth or bob or
    Message 1 of 6 , Jul 24, 2003
    • 0 Attachment
      Okay... here's a test case I am currently working on (RNA). Tell me if this
      looks good or not:

      Key:
      {id} would be something like "seairth" or "bob" or "cmhinson" or
      whatever.
      {abc} is currently a 32-hex character representation of a random 16-byte
      number.
      {uri} is a URL-Encoded URI to be used in a query string
      "Auth-" indicates these methods require HTTP Authentication.
      note: almost all of the names are changable (at least until there are
      resources bound to them).

      /{id}
      POST agreements, GET user-defined page (likely HTML)
      /{id}/inbox/{abc}
      POST notifications (e.g. send {id} a notification)
      /{id}/notifications/{abc}
      GET notificaction (e.g. notification sent to others)


      /{id}/access
      Auth-GET returns the list of URIs to access the following resources
      (e.g. /{id}/received, /{id}/agreements, etc.)
      /{id}/notifications
      Auth-GET returns the list of notifications user has created
      Auth-POST to create a new notification.
      /{id}/received
      Auth-GET returns list of URIs to received notifications
      /{id}/received/{abc}
      Auth-GET returns a received notification
      Auth-DELETE deletes a received notification
      /{id}/agreements
      Auth-GET returns list of URIs to existing agreements
      Auth-POST to create a new agreement returns agreement URI
      /{id}/agreements/{abc}
      Auth-GET returns an agreement
      Auth-PUT updates an agreement
      Auth-DELETE deletes an agreement
      /{id}/sent
      Auth-GET returns a list of individuals sent notifications
      Auth-POST to send a notification (after creating the notification)
      /{id}/sent/{abc}
      Auth-GET returns "record" on the sending of a notification to an
      individual
      Auth-PUT updates the "record"
      Auth-DELETE deletes the "record"
      /{id}/settings
      Auth-GET returns settings
      Auth-PUT updates settings

      The above URIs are broken into two groups. The first group of URIs are
      those that are accessible by anyone (as long as they know the actual URI),
      and are defined by the RNA spec. The second group of URIs are those that
      are accessible only to the "owner" of {id}. Only XML documents are passed,
      containing only data (no presentation). This group of URIs would likely be
      accessed by a client program and not directly by a user.

      Now, I am also trying to write a web-based (html) client to demonstrate the
      application. Originally, the client had a series of URIs that more or less
      mapped to several of the URIs above. However, this was getting confusing,
      since I needed additional things like edit windows and

      /client?uri={uri}
      Auth-GET returns the appropriate resource representation
      {uri} must be one of the URIs in the second group above. The
      "/{id}/access" URI would be the "main" URI, which would return
      the entry page, main menu, etc.
      /client/addform?uri={uri}
      Auth-GET returns the appropriate form
      Auth-POST submits the form
      {uri} must be one of the "container" URIs (e.g. "/{id}/agreements")
      mentioned above that accepts POST (client internally POSTs XML to the
      target {uri}).
      /client/editform?ur={uri}
      Auth-GET returns the appropriate form
      Auth-POST submits the form
      {uri} must be one of the individual resource URIs (e.g.
      "/{id}/agreements/{abc}") mentioned above that accepts PUT (client
      internally updates using PUT to the target {uri}).
      /client/delete?uri={uri}
      Auth-POST submits form
      {uri} must be a parent URI of the URI that will be deleted (which is
      passed in the form itself). Response returns the equivalent of
      "GET /client?{uri}" (minus the deleted resource).

      In general, the idea is that the appropriate screen according to the value
      of {uri} is returned. For clarity, look at the following examples:

      GET /client?uri={/{id}/access}
      returns the main menu options
      GET /client?uri={/{id}/settings}
      returns a static view of the current settings.
      GET /client/editform?uri={/{id}/settings}
      returns a form for editing changes.
      GET /client?uri={/{id}/agreements}
      returns a static list of the agreements.
      GET /client/addform?uri={/{id}/agreements}
      returns form to add an agreement.
      etc.

      Otherwise, the client is designed to work with any implementation that uses
      the XML documents associated to the second group of URIs above. As a
      result, it would be possible to use the same client to access entirely
      different servers as long as the XML interface stayed the same. Of course,
      this is all conceptual now, so I am sure there are some details that I have
      overlooked which may make some or all of this approach difficult to do.

      But, as a general pattern, what does everyone think?

      ---
      Seairth Jacobs
      seairth@...
    • Chuck Hinson
      Seairth Jacobs wrote: [ . . .] ... Did you forget Auth_GET to get the form? ... This looks more or less like the approach that I use as far as treating UI
      Message 2 of 6 , Jul 24, 2003
      • 0 Attachment
        Seairth Jacobs wrote:
        [ . . .]

        >Now, I am also trying to write a web-based (html) client to demonstrate the
        >application. Originally, the client had a series of URIs that more or less
        >mapped to several of the URIs above. However, this was getting confusing,
        >since I needed additional things like edit windows and
        >
        >/client?uri={uri}
        > Auth-GET returns the appropriate resource representation
        > {uri} must be one of the URIs in the second group above. The
        > "/{id}/access" URI would be the "main" URI, which would return
        > the entry page, main menu, etc.
        >/client/addform?uri={uri}
        > Auth-GET returns the appropriate form
        > Auth-POST submits the form
        > {uri} must be one of the "container" URIs (e.g. "/{id}/agreements")
        > mentioned above that accepts POST (client internally POSTs XML to the
        > target {uri}).
        >/client/editform?ur={uri}
        > Auth-GET returns the appropriate form
        > Auth-POST submits the form
        > {uri} must be one of the individual resource URIs (e.g.
        > "/{id}/agreements/{abc}") mentioned above that accepts PUT (client
        > internally updates using PUT to the target {uri}).
        >/client/delete?uri={uri}
        >
        Did you forget Auth_GET to get the form?

        > Auth-POST submits form
        > {uri} must be a parent URI of the URI that will be deleted (which is
        > passed in the form itself). Response returns the equivalent of
        > "GET /client?{uri}" (minus the deleted resource).
        >
        >

        This looks more or less like the approach that I use as far as treating
        UI element as resources. I'd probably change the syntax of your URI
        namespace, but that's just personal perference (i.e, I cant give a good
        reason why you shouldn't do it the way you are).

        >In general, the idea is that the appropriate screen according to the value
        >of {uri} is returned. For clarity, look at the following examples:
        >
        > GET /client?uri={/{id}/access}
        > returns the main menu options
        > GET /client?uri={/{id}/settings}
        > returns a static view of the current settings.
        > GET /client/editform?uri={/{id}/settings}
        > returns a form for editing changes.
        > GET /client?uri={/{id}/agreements}
        > returns a static list of the agreements.
        > GET /client/addform?uri={/{id}/agreements}
        > returns form to add an agreement.
        > etc.
        >
        >

        These seem fine, although I personally would change the structure of the
        URIs to something like
        GET /client/menu?id={id}
        GET /client/settingsviewer?id={id}
        GET /client/settingseditor?id={id}
        GET /client/agreementsviewer?id={id}
        GET /client/agreementscreator?id={id}

        Again, this is just a reflection of the way I'm doing things now - I
        can't give any justification for doing it one way or the other (other
        than it makes more sense to me). (It also assumes that I haven't
        misinterpreted the intent of the examples you gave.)

        --Chuck
      • Seairth Jacobs
        From: Chuck Hinson ... I hand t originally planned on it, but such a form could have it s advantages (like deleting multiple resources at
        Message 3 of 6 , Jul 24, 2003
        • 0 Attachment
          From: "Chuck Hinson" <cmhinson@...>
          > >/client/delete?uri={uri}
          > >
          > Did you forget Auth_GET to get the form?

          I hand't originally planned on it, but such a form could have it's
          advantages (like deleting multiple resources at a time) On the other hand,
          it might also be possible to drop the whole /delete bit and add a POST
          /client?uri={uri} that could handle the delete. This second approach would
          likely be cleaner anyhow...

          >
          > > Auth-POST submits form
          > > {uri} must be a parent URI of the URI that will be deleted (which is
          > > passed in the form itself). Response returns the equivalent of
          > > "GET /client?{uri}" (minus the deleted resource).
          > >
          > >
          >
          > This looks more or less like the approach that I use as far as treating
          > UI element as resources. I'd probably change the syntax of your URI
          > namespace, but that's just personal perference (i.e, I cant give a good
          > reason why you shouldn't do it the way you are).
          >
          > >In general, the idea is that the appropriate screen according to the
          value
          > >of {uri} is returned. For clarity, look at the following examples:
          > >
          > > GET /client?uri={/{id}/access}
          > > returns the main menu options
          > > GET /client?uri={/{id}/settings}
          > > returns a static view of the current settings.
          > > GET /client/editform?uri={/{id}/settings}
          > > returns a form for editing changes.
          > > GET /client?uri={/{id}/agreements}
          > > returns a static list of the agreements.
          > > GET /client/addform?uri={/{id}/agreements}
          > > returns form to add an agreement.
          > > etc.
          > >
          > >
          >
          > These seem fine, although I personally would change the structure of the
          > URIs to something like
          > GET /client/menu?id={id}
          > GET /client/settingsviewer?id={id}
          > GET /client/settingseditor?id={id}
          > GET /client/agreementsviewer?id={id}
          > GET /client/agreementscreator?id={id}
          >
          > Again, this is just a reflection of the way I'm doing things now - I
          > can't give any justification for doing it one way or the other (other
          > than it makes more sense to me). (It also assumes that I haven't
          > misinterpreted the intent of the examples you gave.)

          Except in my examples above, which I don't think I have made very clear
          (sorry) is that {/{id}/access} would actually be something like
          "http://example.invalid/rna/seairth/access" (notice the last part of the
          path). As a result, above examples would look more like:

          GET /client?uri=http://example.invalid/rna/seairth/access
          GET /client?uri=http://example.invalid/rna/seairth/settings
          GET /client/editform?uri=http://example.invalid/rna/seairth/settings
          GET /client?uri=http://example.invalid/rna/seairth/agreements
          GET /client/addform?uri=http://example.invalid/rna/seairth/agreements

          This would also allow the client's host server to be independent, meaning I
          could access an RNA interface on http://example.invalid from
          http://www.sample.invalid Now, I suppose you could have something like:

          GET /client/menu?id=http://example.invalid/rna/seairth/
          GET /client/settingsviewer?id=http://example.invalid/rna/seairth/
          GET /client/settingseditor?id=http://example.invalid/rna/seairth/
          GET /client/agreementsviewer?id=http://example.invalid/rna/seairth/
          GET /client/agreementscreator?id=http://example.invalid/rna/seairth/

          However, what would the URI be when you wanted to work with a specific
          agreement?

          ---
          Seairth Jacobs
          seairth@...
        • Seairth Jacobs
          From: Seairth Jacobs ... [snip] ... the ... less ... [snip] ... [snip] Well, it occurs to me that there are a few design problems
          Message 4 of 6 , Jul 24, 2003
          • 0 Attachment
            From: "Seairth Jacobs" <seairth@...>
            >
            [snip]
            > Now, I am also trying to write a web-based (html) client to demonstrate
            the
            > application. Originally, the client had a series of URIs that more or
            less
            > mapped to several of the URIs above. However, this was getting confusing,
            > since I needed additional things like edit windows and
            >
            > /client?uri={uri}
            > Auth-GET returns the appropriate resource representation
            > {uri} must be one of the URIs in the second group above. The
            > "/{id}/access" URI would be the "main" URI, which would return
            > the entry page, main menu, etc.
            [snip]
            > In general, the idea is that the appropriate screen according to the value
            > of {uri} is returned. For clarity, look at the following examples:
            >
            > GET /client?uri={/{id}/access}
            > returns the main menu options
            [snip]

            Well, it occurs to me that there are a few design problems here...

            First, suppose I had an RNA address of http://example.com/rna/seairth and
            the client software was at http://example.com/rnaclient. According to the
            above stuff, the 'entry-point' would be:

            http://example.com/rnaclient?uri=http://example.com/rna/seairth/access

            Frankly, this isn't very user-friendly. First, the URL is way to long to
            have to type in. Second, it requires me to know/remember the URI of my
            "access" resource. So what would be some solutions? So far, I have thought
            of the following (along with their limitations):

            1) The client could have a "default" URI, but this would only be useful
            where a particular copy of the client was being used by one person only.

            2) Instead, one could use just the RNA Address
            (http://example.com/rna/seairth) and the client would auto-append the
            "access" bit. If the server returned a 404, it could then try other
            possibilities, effectively hunting for the interface. This solution is not
            very flexible, since all it would take is a particular inplementation to
            change the path slightly (e.g. "client-access") in order for the client to
            fail discovery.

            3) If no uri is given, show a simple form requesting the appropriate access
            URI. Once given, store as a cookie to auto-fill the textbox in future.
            Problems: not portable, still requires knowledge of access URI, etc.

            4) Double up the access URI and the RNA address. Since the only purpose of
            the access URI is to return an xml document, it would be possible to use
            conneg on a GET of the RNA Address. This way, a user would only have to
            know their own RNA Address (which they would anyhow). This could be coupled
            with #3 above, where the coookie bit would only be a convenience. The down
            side is that I'm not too crazy about overloading the RNA Address like this
            (purely from a technical POV; I think end-users would be oblivious and
            therefore fine with it).

            5) Move the client to be under the RNA Address, effectively replacing the
            "access URI". Through conneg, it would still be possible to return the
            original XML document from the client URI so that "thick" clients could
            still have access. The main advantage here is that the URI would be
            memorable (e.g. http://example.com/rna/seairth/client). However, it seems
            somewhat like overkill to pass entire URIs in the query string, esp. since
            it would be unlikely that you would use the client to access any RNA address
            other than the one it was under. On the other hand, I could be wrong here.
            For instance, this would allow one to customize the look-and-feel of the
            client program, then access other RNA Addresses while continuing to keep
            that look-and-feel. When accessing another site, you would have to use
            something akin to the original syntax (e.g.
            http://example.com/rna/seairth/client?uri=http://example.com/rna/bob), but
            it's probably fine at that point.



            The other problem is that the current approach would require a GET of the
            "access URI" resource for every request in order to determine what the
            actual uri parameter is pointing to. For instance, in order to understand
            the following:

            GET /client/addform?uri=http://example.com/rna/seairth/agreements

            I would have to first do a GET on the "access URI". Now, given the above
            URI, the access URI isn't known (unless using solution #4 above). It seems
            to me that there are two possible approaches (other than #4):

            1) To change the structure so that everything pointed to by the access URI
            was under the access URI (e.g. /{id}/access/agreements,
            /{id}/access/settings, etc.), which doesn't seem to be a very good solution.
            While it may give access to the "access URI" (in a not-so-opaque manner), it
            still means that an additional GET is required to understand the bits
            underneath it.

            2) To go Chuck's way, sort of. He suggested:

            > GET /client/menu?id={id}
            > GET /client/settingsviewer?id={id}
            > GET /client/settingseditor?id={id}
            > GET /client/agreementsviewer?id={id}
            > GET /client/agreementscreator?id={id}

            Where I took {id} as I meant it in the original post ( "something like
            'seairth' or 'bob' or 'cmhinson'"). Instead, they could be:

            GET /client/menu?id={uri}
            GET /client/settingsviewer?id={uri}
            GET /client/settingseditor?id={uri}
            GET /client/agreementsviewer?id={uri}
            GET /client/agreementscreator?id={uri}

            In other words, when you get back the initial "access URI" list, they are
            translated into meaningful (to the client) URIs that would no longer require
            additional accesses to the "access URI" list. For instance, a request gets
            back the list of agreements:

            http://example.com/rna/seairth/agreements/123
            http://example.com/rna/seairth/agreements/456

            This would be translated into client-specific URIs looking something like:


            http://example.com/rnaclient/agreementviewer?uri=http://example.com/rna/seairth/agreements/123

            http://example.com/rnaclient/agreementeditor?uri=http://example.com/rna/seairth/agreements/123


            http://example.com/rnaclient/agreementviewer?uri=http://example.com/rna/seairth/agreements/456

            http://example.com/rnaclient/agreementeditor?uri=http://example.com/rna/seairth/agreements/456

            The uri is still intact (and totally opaque) and the client program still
            implicitly knows what the resource at the other end of the URI is (though it
            should probably validate anyhow).


            So, for the second problem, I'd be likely to go with option #2. For the
            first problem, I am leanding towards #5, but am unsure. Any thoughts?

            ---
            Seairth Jacobs
            seairth@...
          • Chuck Hinson
            ... I m not sure I would worry too much about the URI being too long. No matter what the length, the user will probably just bookmark it anyway. If your
            Message 5 of 6 , Jul 24, 2003
            • 0 Attachment
              Seairth Jacobs wrote:

              >From: "Seairth Jacobs" <seairth@...>
              >
              >
              >[snip]
              >
              >
              >>Now, I am also trying to write a web-based (html) client to demonstrate
              >>
              >>
              >the
              >
              >
              >>application. Originally, the client had a series of URIs that more or
              >>
              >>
              >less
              >
              >
              >>mapped to several of the URIs above. However, this was getting confusing,
              >>since I needed additional things like edit windows and
              >>
              >>/client?uri={uri}
              >> Auth-GET returns the appropriate resource representation
              >> {uri} must be one of the URIs in the second group above. The
              >> "/{id}/access" URI would be the "main" URI, which would return
              >> the entry page, main menu, etc.
              >>
              >>
              >[snip]
              >
              >
              >>In general, the idea is that the appropriate screen according to the value
              >>of {uri} is returned. For clarity, look at the following examples:
              >>
              >> GET /client?uri={/{id}/access}
              >> returns the main menu options
              >>
              >>
              >[snip]
              >
              >Well, it occurs to me that there are a few design problems here...
              >
              >First, suppose I had an RNA address of http://example.com/rna/seairth and
              >the client software was at http://example.com/rnaclient. According to the
              >above stuff, the 'entry-point' would be:
              >
              >http://example.com/rnaclient?uri=http://example.com/rna/seairth/access
              >
              >Frankly, this isn't very user-friendly. First, the URL is way to long to
              >have to type in. Second, it requires me to know/remember the URI of my
              >"access" resource.
              >

              I'm not sure I would worry too much about the URI being too long. No
              matter what the length, the user will probably just bookmark it anyway.

              If your client software has the same host as your RNA address and your
              access URIs are always the same except for the id part (seairth above),
              then I could easily see where you have a default page at
              http://example.com/rnaclient that asks you for your id (seairth in this
              case) and then fowards/redirects you to the appropriate page using the
              URI above. Once there, the user shouldn't have to type any URIs - he
              should be able to click his way anywhere else he needs to go. And given
              one URI, the server should be able to generate content containing
              appropriately formed URIs for that user.


              >So what would be some solutions? So far, I have thought
              >of the following (along with their limitations):
              >
              >1) The client could have a "default" URI, but this would only be useful
              >where a particular copy of the client was being used by one person only.
              >

              This isnt a whole lot different than the way mail clients work right
              now. Each user has a separate copy of the client configured with their
              mail server info.

              >
              >2) Instead, one could use just the RNA Address
              >(http://example.com/rna/seairth) and the client would auto-append the
              >"access" bit. If the server returned a 404, it could then try other
              >possibilities, effectively hunting for the interface. This solution is not
              >very flexible, since all it would take is a particular inplementation to
              >change the path slightly (e.g. "client-access") in order for the client to
              >fail discovery.
              >

              Why bother with the hunting part? For the sake of interop, just require
              that the access page is the rna address with /access appended. Once
              enough implementations do it that way, any implementation that does it
              differently will be considered broken.

              >
              >3) If no uri is given, show a simple form requesting the appropriate access
              >URI. Once given, store as a cookie to auto-fill the textbox in future.
              >Problems: not portable, still requires knowledge of access URI, etc.
              >

              Uggh. Plenty of other options. Let's drop this one.

              >4) Double up the access URI and the RNA address. Since the only purpose of
              >the access URI is to return an xml document, it would be possible to use
              >conneg on a GET of the RNA Address. This way, a user would only have to
              >know their own RNA Address (which they would anyhow). This could be coupled
              >with #3 above, where the coookie bit would only be a convenience. The down
              >side is that I'm not too crazy about overloading the RNA Address like this
              >(purely from a technical POV; I think end-users would be oblivious and
              >therefore fine with it).
              >

              What's the hangup. Actually, the only problems I can think of are
              semantic, not technical - in one case the URI identifies a user, in the
              other, the URI identifies the user's access page. Given recent
              discussion on the TAG list, this might not be the 'purest' way to do
              things, but it sure seems practical.

              >
              >5) Move the client to be under the RNA Address, effectively replacing the
              >"access URI". Through conneg, it would still be possible to return the
              >original XML document from the client URI so that "thick" clients could
              >still have access. The main advantage here is that the URI would be
              >memorable (e.g. http://example.com/rna/seairth/client). However, it seems
              >somewhat like overkill to pass entire URIs in the query string, esp. since
              >it would be unlikely that you would use the client to access any RNA address
              >other than the one it was under. On the other hand, I could be wrong here.
              >For instance, this would allow one to customize the look-and-feel of the
              >client program, then access other RNA Addresses while continuing to keep
              >that look-and-feel. When accessing another site, you would have to use
              >something akin to the original syntax (e.g.
              >http://example.com/rna/seairth/client?uri=http://example.com/rna/bob), but
              >it's probably fine at that point.
              >

              Why not http://example.com/rna/client?uri=http://example.com/rna/bob
              when you're on a different server?

              Why does bob need to know about seairth (or seairth's rna address)?

              I think any of the above would probably work out just fine (although I
              really dont like 3).

              --Chuck
            • Seairth Jacobs
              From: Chuck Hinson ... Yes, but bookmarks aren t very portable. If you sit down at any other browser, your SOL. Bookmarks should be a
              Message 6 of 6 , Jul 25, 2003
              • 0 Attachment
                From: "Chuck Hinson" <cmhinson@...>
                > >
                > >http://example.com/rnaclient?uri=http://example.com/rna/seairth/access
                > >
                > >Frankly, this isn't very user-friendly. First, the URL is way to long to
                > >have to type in. Second, it requires me to know/remember the URI of my
                > >"access" resource.
                > >
                >
                > I'm not sure I would worry too much about the URI being too long. No
                > matter what the length, the user will probably just bookmark it anyway.

                Yes, but bookmarks aren't very portable. If you sit down at any other
                browser, your SOL. Bookmarks should be a convenience, not a solution.

                > >2) Instead, one could use just the RNA Address
                > >(http://example.com/rna/seairth) and the client would auto-append the
                > >"access" bit. If the server returned a 404, it could then try other
                > >possibilities, effectively hunting for the interface. This solution is
                not
                > >very flexible, since all it would take is a particular inplementation to
                > >change the path slightly (e.g. "client-access") in order for the client
                to
                > >fail discovery.
                > >
                >
                > Why bother with the hunting part? For the sake of interop, just require
                > that the access page is the rna address with /access appended. Once
                > enough implementations do it that way, any implementation that does it
                > differently will be considered broken.

                To my knowledge, it's bad form to "force" a specific URI naming convention.
                For example, look at the conversations on the www-tag concerning
                "favicon.ico", "robots.txt", and "p3p" a couple months ago.

                > >4) Double up the access URI and the RNA address. Since the only purpose
                of
                > >the access URI is to return an xml document, it would be possible to use
                > >conneg on a GET of the RNA Address. This way, a user would only have to
                > >know their own RNA Address (which they would anyhow). This could be
                coupled
                > >with #3 above, where the coookie bit would only be a convenience. The
                down
                > >side is that I'm not too crazy about overloading the RNA Address like
                this
                > >(purely from a technical POV; I think end-users would be oblivious and
                > >therefore fine with it).
                > >
                >
                > What's the hangup. Actually, the only problems I can think of are
                > semantic, not technical - in one case the URI identifies a user, in the
                > other, the URI identifies the user's access page. Given recent
                > discussion on the TAG list, this might not be the 'purest' way to do
                > things, but it sure seems practical.

                I agree. One could probably restate it so that it sounded kosher, but it
                still doesn't feel right somehow...

                > >
                > >5) Move the client to be under the RNA Address, effectively replacing the
                > >"access URI". Through conneg, it would still be possible to return the
                > >original XML document from the client URI so that "thick" clients could
                > >still have access. The main advantage here is that the URI would be
                > >memorable (e.g. http://example.com/rna/seairth/client). However, it
                seems
                > >somewhat like overkill to pass entire URIs in the query string, esp.
                since
                > >it would be unlikely that you would use the client to access any RNA
                address
                > >other than the one it was under. On the other hand, I could be wrong
                here.
                > >For instance, this would allow one to customize the look-and-feel of the
                > >client program, then access other RNA Addresses while continuing to keep
                > >that look-and-feel. When accessing another site, you would have to use
                > >something akin to the original syntax (e.g.
                > >http://example.com/rna/seairth/client?uri=http://example.com/rna/bob),
                but
                > >it's probably fine at that point.
                > >
                >
                > Why not http://example.com/rna/client?uri=http://example.com/rna/bob
                > when you're on a different server?
                >
                > Why does bob need to know about seairth (or seairth's rna address)?

                Normally, bob wouldn't need to know about seairth's RNA address. bob would
                likely access http://example.com/rna/bob/client. However, I have multiple
                identities: personal, work, etc. In each of those cases, I may have a
                separate RNA Address. I may have full control over my personal address and
                client, and therefore may customize it in various ways. When accessing my
                work address, I *could* use the client at that address, but I could also use
                the client at my personal address which has my personal customizations.

                But this does bring up another interesting issue. It would be possible to
                use any web client to access any RNA Address. As a result, I could use your
                client to access my address. Now, I don't know *why* I would want to do
                such a thing, esp. since I would be giving you the oportunity to discover my
                auth-info. But it is possible. Of course, it would also be possible to
                just disable the feature that would allow such a thing. For most people,
                this would likely be the prefered setting. Another possbility to would be
                to require independent authentication for use of the client. In most cases,
                the authentication info would be the same as for the associated RNA Address
                itself. However, in the case where a second address is accessed (e.g.
                work), it would probably be necessary to maintain a separate profile with
                separate authentication information so that the client could properly access
                the remote RNA Address. This way, only addresses specified in profiles
                would be accessible.

                And a final thought (for now)... If one really wanted to set up a server to
                use a format like

                > http://example.com/rna/client?uri=http://example.com/rna/bob

                This could be done with a redirection. All bob would have to remember is
                http://example.com/rna/bob/client. Upon typing that in, he would be
                redirected to the extended version. This makes it easy for him to remember
                while still allowing flexibility in the way that the client is implemented.

                > I think any of the above would probably work out just fine (although I
                > really dont like 3).

                The more I think about it, the more #5 seems like the way to go.
                ---
                Seairth Jacobs
                seairth@...
              Your message has been successfully submitted and would be delivered to recipients shortly.