On 15 December 2012 20:48, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> Colin,
>
> thank you for the detailed explanations. Well written, and they make a
> lot of sense!
>
> Taking the example of the new Squeak website
>
>    http://box3.squeak.org:8624/yqKyLzH7r9ePyzIWOLUBWO9x
>
> points to the Squeak community web page (mailing lists etc.).
>
> It  is exciting to see this RESTful behavior in action. This opens up
> a lot of new options.
>
> Chris, BTW the blue bar appears double in IE9 whereas in FF17 it is fine.
>
> I did not realize that the new Squeak website has this behavior as the
> URL looked very Seaside-like. So I did not even try to look at the url
>
>    http://box3.squeak.org:8624/yqKyLzH7r9ePyzIWOLUBWO9x
>
> in different browsers.
>
> The immediate question which now comes up is
>
> how can we have something like
>
>    http://box3.squeak.org:8624/community
>
> i.e.
>
>      yqKyLzH7r9ePyzIWOLUBWO9x
>
> replaced by
>
>      community
>
> ?

You just use a different Locator. Reflect-Core's ParamLocator might be
a completely terrible example of the idea, but my hacking currently
has URLs like http://127.0.0.1:9090/organization/classes-in/Collections-Arrayed
which look pretty readable. Guessable too, but that's the intent
_here_: other applications might not desire guessable URLs.

frank

> --Hannes
>
> On 12/15/12, Colin Putney <colin at wiresong.com> wrote:
>> On Sat, Dec 15, 2012 at 10:27 AM, Chris Cunnington <
>> smalltalktelevision at gmail.com> wrote:
>>
>>>  Why are the tokens in Altitude urls called RESTful?
>>>
>>
>> This is an important and subtle topic. Grappling with it is what drove the
>> development if Altitude, first as a hacked up version of Seaside, and later
>> as a complete rewrite using Xtreams.
>>
>> I'm hardly an expert on this, but I try to understand REST from the
>> original sources. The term is an abbreviation of "representational state
>> transfer" and refers to an architectural style for distributed applications
>> that was described in Roy Fieldings doctoral dissertation. [1] You'll note
>> that "R. Fielding" first is on the list of authors of RFC 2616 [2], which
>> describes HTTP. With a pedigree like that, it's no surprise that REST is
>> the most important buzzword of the web development world.
>>
>> For me, the simplest way to think about REST is to imagine an old-school
>> static web site: a directory of files being served by a generic Apache
>> installation, with no fancy plugins, mod_rewrite magic or anything like
>> that. You have a simple convention where the web page corresponding to a
>> directory is found in a file called index.html inside that directory, but
>> otherwise the directory tree in your DOCUMENT_ROOT is mapped directly into
>> the URL space for that server: http://example.com/foo/ will fetch the
>> contents of $DOCUMENT_ROOT/foo/index.html, and
>> http://example/favicon.icowill be found at $DOCUMENT_ROOT/favicon.ico.
>>
>> There are a couple of important properties of a setup like this:
>>
>> 1. There's a single entry point with a well-known URL: http://example.com/.
>> The client begins by downloading that page, and from there it discovers
>> other urls where related resources can be found—css, images, javascript
>> etc. There might also be hyperlinks to other pages, which the user might
>> click on to navigate to other pages. The important bit is that all URLs are
>> provided by the server. At no point does the client generate a url by
>> following a convention. (ie, something like "the resource I want is of type
>> Person, and has ID #3, and I want the HTML page that describes that person,
>> so the url will be /people/3.html"). The urls may in fact follow such a
>> convention, but that's solely for the convenience of the server, and the
>> client always receives URLs explicitly, though they might be in relative
>> rather than absolute form.
>>
>> 2. The client-server transactions are stateless. Each request is
>> independent, and the server doesn't interpret requests in a client-specific
>> context. As a consequence, the the URLs that link one document to another
>> are the same for all clients.
>>
>> Now, consider Seaside;
>>
>> 1. A Seaside application follows the same pattern, with a well-known entry
>> point, and all URLs provided by the server.
>>
>> 2. However, a seaside application don't have stateless transactions. Each
>> url generated by Seaside contains a session identifier and a continuation
>> identifier, which refer to client-specific context stored on the server.
>> Thus each client's view of a particular page is unique. Each page is
>> located at a client-specific URL and has links to other pages at
>> client-specific URLs. This is why Seaside is not RESTful. (For example,
>> open up http://www.squeaksource.com/. Now open the same URL in another tab.
>> The two tabs will have different urls in their location fields. Now
>> mouse-over the link to the "Projects" page. Each tab will have a different
>> URL for that link.)
>>
>> Now, the reason Seaside is such a good framework is that it provides an
>> abstraction that hides all the details of the way that state is threaded
>> through the client-server transactions in a web app. It generates urls,
>> form field names, session ids etc so that application developers don't have
>> to concern themselves with the details of marshalling and unmarshalling the
>> state of their application into strings on each request.
>>
>> Altitude tries to provide that same level of abstraction in a RESTful way.
>> That is, it behaves like an old-school static web site with respect to
>> property #2: it produces consistent urls for the "same" resources, and
>> doesn't store client-specific context on the server.
>>
>> Andreas Raab criticized Seaside because SqueakSource cannot be indexed by
>>> Google. The Altitude url tokens look extremely similar to Seaside's.
>>>
>>> 1. If they are different, how?
>>>
>>
>> Yes. They are superficially similar, in that they are opaque strings
>> generated by the server. But if you go to http://box3.squeak.org:8624/ and
>> do the same experiment as I described above with regard to SqueakSource,
>> you'll see that the URLs are opaque, but consistent. The home page is
>> always at /, the community page is always at /yqKyLzH7r9ePyzIWOLUBWO9x, for
>> all clients.
>>
>>
>>> 2. Can an Altitude application be indexed by Google? If so, which
>>> subclass
>>> of ALUrlStrategy would be employed?
>>>
>>
>> Yes. Imagine that Google crawls the new site you've created for Squeak. It
>> will index /yqKyLzH7r9ePyzIWOLUBWO9x and then when somebody does a search
>> for "Squeak community" that page will come up (we hope). The user clicks on
>> the link, and arrives at /yqKyLzH7r9ePyzIWOLUBWO9x, and sees the community
>> page. Great! If that were a Seaside web site, the user would get a 404
>> error, because the page that Google saw has expired from the server.
>>
>> Any strategy could be used, and the site would still be indexable. The
>> strategies have differences which might make one strategy or another
>> desirable for different purposes, but RESTfulness isn't a property of the
>> structure of the URL so much as the way the server handles them. That's why
>> the locator is named Restful, not the strategies.
>>
>> Does this make sense?
>>
>> Colin
>>
>>
>> [1]  https://www.ics.uci.edu/~fielding/pubs/dissertation/top
>> [2]  http://tools.ietf.org/html/rfc2616
>> [3] Well, actually it does, but only for purposes of ranking, not indexing.
>>
>