[Bese-devel] Developing non-interactive applications.

[Marco Baringer]

pjd tech <pjdtech2000 at gmail.com> writes:

> It means there is no need for
>    - back tracking (no BACK button)
>    - No cloning.
>
> On a further note,  
>    - Client doesnt support cookies.
>    - But the binary protocol does support URL rewriting. As part of
> each reply, server can send a URL for the client where to POST the
> next message.
>
> I just would like to use CPS style of programming so that my server
> logic is linear instead of a state machine.

i don't completly understantd the details (and the details are very
important at this point), but i'll try anyway.

you have a server and a client (interactive or not it doesn't matter
much at this point). the client sends http requests and the server
resonds. unlike a regular web page we don't have multiple links to
chose from but only one. 

assuming you want to reuse UCW as much as possible:

your publicly visible url (the first url clients request from the
server) would be a ucw entry point:

(defentry-point "/start" (:application my-app) 
    ([request params for first request])
  (do-stuff [request params])
  (call 'first-response-object)
  (do-more-stuff)
  (call 'second-response-object)
  ...)

however the responses from the server aren't html but are some binary
protocol, all this means is that you'll need to write your own
render-on methods whcih don't use tal or yaclml (which is fine) [you
still want the http response headers right?]:

(defmethod render-on ((res response) (comp first-response-object))
  (write-as-binary-protocol comp :stream (content-stream res)))

which basically leaves use with one unanswered question: what url do
we send to the client in such a fashion that the next request (the one
after first-response-object) "returns" us to the right place in the
entry-point? easy (if you know ucw :)):

(defmethod render-on ((res response) (comp first-response-object))
  (write-as-binary-protocol comp 
    :stream (content-stream res)
    :next-url (compute-url comp
                :action-id (make-new-action (context.current-frame *context*)
                                            (lambda () (ok comp))))))

if you tell the client to send their next request to :next-url then
the (call 'first-response-object) form will "return" and execution in
the defentry-point will continue. The important thing to notice is
that every ucw component (as long as its a subclass of
standard-component) can use the OK action. if we want the (call
'first-response-object) form to return a value other nil we just need
to pass that value to OK:

(ok comp [call form's return value])

> Is there some way I can adapt UCW to do such a thing? Or would I need
> to start with arnesi, and write UCW like framework without the GUI
> bits ?

i would suggest, though it may seem harder at first, to mold ucw into
what you need instead of trying to rewrite ucw (i've already written
ucw once and while it's a LOT of fun it's also a lot of work).

i'd start off with something very simple which works (along the lines
of the code sample above). you can then later, when your sure it works
and your sure you want to use UCW, define your own session and
component object and eliminate the backtracking and other component
overhead. this isn't very difficult to do, i'm just suggesting that
you start by getting something (anything) working instead of trying to
do it all at once.


hth.
-- 
-Marco Baringer

Baringer Electronics and Software Engineering
www.bese.it