> Hi Sebastian,
>
> my remark didn't intend to start a Seaside vs. REST flamewar.
> What I wanted to say is that since Seaside's architecture is
> completely different from what REST requires, having pretty
> URLs doesn't make Seaside any more RESTful than not having them.
>
> I also believe that any Seaside vs. REST comparison is
> useless: Seaside is a framework for building web applications
> whose primary medium is the web browser; REST is an
> architecture for creating web services that may also be
> consumed by a web browser.
>
> Giovanni
>
>
Good clarification Giovanni. Is anecdotical but related: as I see things
now, the more the framework can help me to use web browsers as "the
hardware" of my apps the more interest I will get on it. But that is
conditioned to the capability of that framework to provides prevention of
the use of smalltalk in a relational way (or other viced ways).
I wasn't yet able to find a paradigm that is more complete than Object
Paradigm, so, I'm sure you already know it can include the relational model
for instance. But using smalltalk that way you know that do not scale in
complexity. So, in other words I'm saying: that the framework should also
provides guarantee of not polluting nor vicing the object paradigm as the
cost of using it because I don't want to compromise my capability of scaling
in complexity.
In this line of thinking you may notice that will came the day in
which we should be capable of feel (as developers) that internet is a mere
"bus" in "the system". Because is transparently solved by developed
frameworks used by our (application and domain model) objects. And that, my
friend, for sure you know, is what internet escence is all about. This will
be clear when you can strip internet of all the envelops, artifices and
moldures it has now and make it became *the* intersticial medium of
comunication between domains. The more scaled one.
All the best,
Sebastian
Locked
