RFC: waiting for a participant

11 views
Skip to first unread message

I. E. Smith-Heisters

unread,
Jun 4, 2010, 8:06:02 PM6/4/10
to ruote
Hi all,

Building on the thread here: http://groups.google.com/group/openwferu-users/browse_thread/thread/88d64384a3015aa7

... our users need to interact with stored workitems, which begs a
question I've seen posted on this list before: how to force Ruote to
behave synchronously, so that users can see their changes to the
system immediately (in our case, they'd otherwise have to reload a web
page).

I refactored John's example, and came up with the following:

----8<----
class PatientParticipant < Ruote::StorageParticipant
class NestedWaitForError < StandardError; end
cattr_accessor :waiting
class << self
def wait_for signal=:next, &block
raise NestedWaitForError, "nesting wait_for is not currently
supported" if self.waiting
begin
self.waiting = [Thread.current, signal]
block.call
Thread.stop if waiting
Thread.current['__patience_result__']
ensure
self.waiting = nil
end
end

def continue workitem
return unless waiting
thread, waiting_for = *waiting
signals = [:next, workitem.participant_name]
if signals.include? waiting_for
thread['__patience_result__'] = workitem
thread.wakeup
end
end
end
def consume workitem
super workitem
self.class.continue workitem.dup
end
end
---->8----

My controller might look like this:

----8<----
FooController < ApplicationController
def update
PatientParticipant.wait_for :next do # "participant_x" works too
# reply to the engine with #params
end
end
end
---->8----

The *only* place I'd use this is where we reply to the engine on
behalf of a user, since I vastly prefer to embrace Ruote's
asynchronous model.

Hope that helps someone.

John Mettraux

unread,
Jun 4, 2010, 10:53:15 PM6/4/10
to openwfe...@googlegroups.com

On Fri, Jun 04, 2010 at 05:06:02PM -0700, I. E. Smith-Heisters wrote:
>
> Building on the thread here: http://groups.google.com/group/openwferu-users/browse_thread/thread/88d64384a3015aa7
>
> ... our users need to interact with stored workitems, which begs a
> question I've seen posted on this list before: how to force Ruote to
> behave synchronously, so that users can see their changes to the
> system immediately (in our case, they'd otherwise have to reload a web
> page).

Hello Ian,

in the context of a "web page", what about having the page refresh itself intermittently, � la Gmail ?

Or if your users have an up-to-date browser, what about [ab]using websockets and let the server notify the web page of new workitems ?

Thanks for sharing your experiences.

It's true that we're all a bit wary of "anticipating the flow", because it usually means that changing the flow will break the anticipations / expectations.

I hope you're having good fun and that ruote helps you in your work.


Cheers,

--
John Mettraux - http://jmettraux.wordpress.com

I. E. Smith-Heisters

unread,
Jun 7, 2010, 4:46:00 PM6/7/10
to ruote

On Jun 4, 7:53 pm, John Mettraux <jmettr...@openwfe.org> wrote:
> in the context of a "web page", what about having the page refresh itself intermittently, la Gmail ?
>
> Or if your users have an up-to-date browser, what about [ab]using websockets and let the server notify the web page of new workitems ?

Yes, we discussed this, and decided that Comet would probably be a
great long-term solution for other situations. It's not appropriate
for this situation because we're already doing a page refresh, and if
the user sees a new page that doesn't have their changes represented,
they might do something drastic like hit their back button. Even if we
automatically update the page once their changes go through (fully
embracing asynchronicity), it might be too late--they might have
already navigated away.

In order for it to work well, the user-interaction cycle would have to
be completely asynchronous. That is, the form submission, and any and
all responses. The degree of change required is way too involved.
Until writing Comet apps becomes as easy or easier than writing
traditional apps, I suspect we'll continue doing it this way.


> Thanks for sharing your experiences.
>
> It's true that we're all a bit wary of "anticipating the flow", because it usually means that changing the flow will break the anticipations / expectations.
>
> I hope you're having good fun and that ruote helps you in your work.

I cannot express in words how awesome ruote is, nor how much it has
helped me in my work. It's one of those things I always thought should
exist, and am thrilled that not only does it finally exist, but that
it's quite nicely executed to boot. Thanks so much for your efforts
building it.

-Ian

>
> Cheers,
>
> --
> John Mettraux -http://jmettraux.wordpress.com
Reply all
Reply to author
Forward
0 new messages