Long running tasks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Long running tasks

Aaron Rosenzweig
Hi, 

Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow. 

Does Seaside have a pre-baked solution for this? 

If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject:

In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline. 

I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link. 

These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters. 

I’ve setup a public demo app / repo to test out these concepts: 


It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk? 

Thanks in advance for any advice you may have,
— Aaron

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Long running tasks

Tobias Pape
Hi

> On 14. Mar 2021, at 19:40, Aaron Rosenzweig <[hidden email]> wrote:
>
> Hi,
>
> Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow.


I've written something like that for SqueakSource3 about 10 years back.

The idea involved:
On Squeak (or Pharo)
        - an ever running background Process with a loop and
        - a shared queue and
        - the Seaside-Processes putting work items there.
        - the background process picks up items off that queue.

On GemStone:
        - a separate "Service-Gem" that loops on a
        - shared (reduced-conflict) Queue
        - the Seaside gem(s) committing items to that queue and
        - the service gem handling them.

Dale Henrichs explained that bit quite well actually here:
        https://github.com/GsDevKit/ServiceVM

Hope that helps.
        -Tobias

>
> Does Seaside have a pre-baked solution for this?
>
> If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject:
> http://onsmalltalk.com/polling-for-long-running-processes
> http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk
>
> In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline.
>
> I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link.
>
> These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters.
>
> I’ve setup a public demo app / repo to test out these concepts:
>
> https://github.com/recurve/ScriptaculistPharoHeySql/
>
> It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk?
>
> Thanks in advance for any advice you may have,
> — Aaron
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Long running tasks

Aaron Rosenzweig
Thanks Tobias, 

That’s a great writeup - I like the looks of WADelayedAnswerDecoration discussed there too! Thanks for the tip. 


On Mar 14, 2021, at 3:17 PM, Tobias Pape <[hidden email]> wrote:

Hi

On 14. Mar 2021, at 19:40, Aaron Rosenzweig <[hidden email]> wrote:

Hi, 

Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow. 


I've written something like that for SqueakSource3 about 10 years back.

The idea involved:
On Squeak (or Pharo)
- an ever running background Process with a loop and
- a shared queue and
- the Seaside-Processes putting work items there.
- the background process picks up items off that queue.

On GemStone:
- a separate "Service-Gem" that loops on a 
- shared (reduced-conflict) Queue
- the Seaside gem(s) committing items to that queue and
- the service gem handling them.

Dale Henrichs explained that bit quite well actually here:
https://github.com/GsDevKit/ServiceVM

Hope that helps.
-Tobias


Does Seaside have a pre-baked solution for this? 

If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject:
http://onsmalltalk.com/polling-for-long-running-processes
http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk

In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline. 

I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link. 

These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters. 

I’ve setup a public demo app / repo to test out these concepts: 

https://github.com/recurve/ScriptaculistPharoHeySql/

It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk? 

Thanks in advance for any advice you may have,
— Aaron
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Long running tasks

Tobias Pape
Hi Aaron


> On 14. Mar 2021, at 21:06, Aaron Rosenzweig <[hidden email]> wrote:
>
> Thanks Tobias,
>
> That’s a great writeup - I like the looks of WADelayedAnswerDecoration discussed there too! Thanks for the tip.

Glad to help.

For the last question you had,
do you mean something like
        Processor yield
or
        10 seconds delay wait
?

Best regards
        -Tobias

>
>
>> On Mar 14, 2021, at 3:17 PM, Tobias Pape <[hidden email]> wrote:
>>
>> Hi
>>
>>> On 14. Mar 2021, at 19:40, Aaron Rosenzweig <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow.
>>
>>
>> I've written something like that for SqueakSource3 about 10 years back.
>>
>> The idea involved:
>> On Squeak (or Pharo)
>> - an ever running background Process with a loop and
>> - a shared queue and
>> - the Seaside-Processes putting work items there.
>> - the background process picks up items off that queue.
>>
>> On GemStone:
>> - a separate "Service-Gem" that loops on a
>> - shared (reduced-conflict) Queue
>> - the Seaside gem(s) committing items to that queue and
>> - the service gem handling them.
>>
>> Dale Henrichs explained that bit quite well actually here:
>> https://github.com/GsDevKit/ServiceVM
>>
>> Hope that helps.
>> -Tobias
>>
>>>
>>> Does Seaside have a pre-baked solution for this?
>>>
>>> If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject:
>>> http://onsmalltalk.com/polling-for-long-running-processes
>>> http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk
>>>
>>> In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline.
>>>
>>> I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link.
>>>
>>> These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters.
>>>
>>> I’ve setup a public demo app / repo to test out these concepts:
>>>
>>> https://github.com/recurve/ScriptaculistPharoHeySql/
>>>
>>> It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk?
>>>
>>> Thanks in advance for any advice you may have,
>>> — Aaron
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Long running tasks

Paul DeBruicker
In reply to this post by Aaron Rosenzweig
http://smalltalkhub.com/pdebruic/ThreadPool/

Is the code from Ramon's blog post & works with Seaside and Pharo/GemStone
and I think Squeak.


 


Aaron Rosenzweig wrote

> Hi,
>
> Last I checked, Seaside is single-threaded which is a “good thing.” That
> said, it implies that every user action must return quickly… perhaps no
> longer than 1 second. If the action takes longer, a chain reaction starts
> to form from multiple “simultaneous” users (not really at-the-same-time
> users, they queue up with the single thread). There are times, in apps
> I’ve written, where the act of clicking a link (or button) is expected to
> take 10 minutes (sometimes half hour). During this time we want to fork a
> thread to do the big task (like generate a report) that doesn’t tie up the
> main thread. This way we can poll every 2 seconds to ask “are you done
> yet?” with a progress bar and then ultimately bring the user back to the
> normal flow.
>
> Does Seaside have a pre-baked solution for this?
>
> If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been
> able to find about the subject:
> http://onsmalltalk.com/polling-for-long-running-processes
> &lt;http://onsmalltalk.com/polling-for-long-running-processes&gt;
> http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk
> &lt;http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk&gt;
>
> In his case, he wanted a page to load immediately but then have a handful
> (or more) ajax requests running in the background pinging other servers to
> tally prices for a travel quote site. Sort of like those interlaced GIF
> images back in the day, his page pops with basic information then
> progressively renders other parts. So his example has maybe 10 threads
> forked for one page to fully load and shows updates inline.
>
> I was thinking more of one page WAProgress (I made that up) with one
> forked thread that monitors its execution and returns when it either
> completes, errors, or the user clicks a cancel link.
>
> These are things baked into WebObjects (NeXT / Apple) and is what my
> buddies and I use daily. We are tiptoeing around the idea of starting new
> web development projects with Smalltalk / Seaside and testing the waters.
>
> I’ve setup a public demo app / repo to test out these concepts:
>
> https://github.com/recurve/ScriptaculistPharoHeySql/
> &lt;https://github.com/recurve/ScriptaculistPharoHeySql/&gt;
>
> It’s an address book application. What I’ll do is modify the delete of a
> contact to fork and render the Progress component and programmatically
> make the delete slow to show the feature. By the way, how do I do the
> equivalent of “Thread.sleep()” in Smalltalk?
>
> Thanks in advance for any advice you may have,
> — Aaron
> _______________________________________________
> seaside mailing list

> seaside@.squeakfoundation

> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside





--
Sent from: http://forum.world.st/Seaside-General-f86180.html
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Long running tasks

Aaron Rosenzweig
Thanks Paul for the link to smalltalk hub with Ramon’s code from the blog post :-) 

Also thanks Tobias for the “10 seconds delay wait" syntax :-) That’s probably what I was looking for. I had seen a concurrency book for Pharo that talked about yield but that doesn’t pause the thread, just makes it lower priority. 

Thanks everyone :-)

On Mar 14, 2021, at 6:44 PM, Paul DeBruicker <[hidden email]> wrote:

http://smalltalkhub.com/pdebruic/ThreadPool/

Is the code from Ramon's blog post & works with Seaside and Pharo/GemStone
and I think Squeak.





Aaron Rosenzweig wrote
Hi, 

Last I checked, Seaside is single-threaded which is a “good thing.” That
said, it implies that every user action must return quickly… perhaps no
longer than 1 second. If the action takes longer, a chain reaction starts
to form from multiple “simultaneous” users (not really at-the-same-time
users, they queue up with the single thread). There are times, in apps
I’ve written, where the act of clicking a link (or button) is expected to
take 10 minutes (sometimes half hour). During this time we want to fork a
thread to do the big task (like generate a report) that doesn’t tie up the
main thread. This way we can poll every 2 seconds to ask “are you done
yet?” with a progress bar and then ultimately bring the user back to the
normal flow. 

Does Seaside have a pre-baked solution for this? 

If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been
able to find about the subject:
http://onsmalltalk.com/polling-for-long-running-processes
&lt;http://onsmalltalk.com/polling-for-long-running-processes&gt;
http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk
&lt;http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk&gt;

In his case, he wanted a page to load immediately but then have a handful
(or more) ajax requests running in the background pinging other servers to
tally prices for a travel quote site. Sort of like those interlaced GIF
images back in the day, his page pops with basic information then
progressively renders other parts. So his example has maybe 10 threads
forked for one page to fully load and shows updates inline. 

I was thinking more of one page WAProgress (I made that up) with one
forked thread that monitors its execution and returns when it either
completes, errors, or the user clicks a cancel link. 

These are things baked into WebObjects (NeXT / Apple) and is what my
buddies and I use daily. We are tiptoeing around the idea of starting new
web development projects with Smalltalk / Seaside and testing the waters. 

I’ve setup a public demo app / repo to test out these concepts: 

https://github.com/recurve/ScriptaculistPharoHeySql/
&lt;https://github.com/recurve/ScriptaculistPharoHeySql/&gt;

It’s an address book application. What I’ll do is modify the delete of a
contact to fork and render the Progress component and programmatically
make the delete slow to show the feature. By the way, how do I do the
equivalent of “Thread.sleep()” in Smalltalk? 

Thanks in advance for any advice you may have,
— Aaron
_______________________________________________
seaside mailing list

seaside@.squeakfoundation

http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside





--
Sent from: http://forum.world.st/Seaside-General-f86180.html
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Long running tasks

Esteban A. Maringolo
In reply to this post by Aaron Rosenzweig
Hi all,

I don't want to hijack this thread, but in all these years my
understanding was that even though most Smalltalks are single
threaded, they can handle HTTP requests concurrently (as long as there
is no other I/O thing blocking, like DB, FS, etc.) because the socket
handling is usually handled multithreaded or non-blocking by the VM,
in Pharo the ZnMultiThreadedServer is there for a reason.

With that assumed, Seaside implements a particular session mutex to
block multiple requests from the same session to execute concurrently
(possibly messing not just the app state, but the continuations for
that session).

So my conclusion has always been that as long as there is no blocking
at the VM level, Seaside can handle requests from different sessions
concurrently.

Is that correct or I got it wrong all this time?

Best regards!

Esteban A. Maringolo

On Sun, Mar 14, 2021 at 3:40 PM Aaron Rosenzweig <[hidden email]> wrote:

>
> Hi,
>
> Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow.
>
> Does Seaside have a pre-baked solution for this?
>
> If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject:
> http://onsmalltalk.com/polling-for-long-running-processes
> http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk
>
> In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline.
>
> I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link.
>
> These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters.
>
> I’ve setup a public demo app / repo to test out these concepts:
>
> https://github.com/recurve/ScriptaculistPharoHeySql/
>
> It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk?
>
> Thanks in advance for any advice you may have,
> — Aaron
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Long running tasks

Sven Van Caekenberghe-2


> On 15 Mar 2021, at 16:30, Esteban Maringolo <[hidden email]> wrote:
>
> Hi all,
>
> I don't want to hijack this thread, but in all these years my
> understanding was that even though most Smalltalks are single
> threaded, they can handle HTTP requests concurrently (as long as there
> is no other I/O thing blocking, like DB, FS, etc.) because the socket
> handling is usually handled multithreaded or non-blocking by the VM,
> in Pharo the ZnMultiThreadedServer is there for a reason.
>
> With that assumed, Seaside implements a particular session mutex to
> block multiple requests from the same session to execute concurrently
> (possibly messing not just the app state, but the continuations for
> that session).
>
> So my conclusion has always been that as long as there is no blocking
> at the VM level, Seaside can handle requests from different sessions
> concurrently.
>
> Is that correct or I got it wrong all this time?

I think you are right, at least that is also my understanding.

Every concurrent request is handled in its own worker thread/process. These are all at the same priority. As long as there is not one of them that locks up the whole VM, by doing a long FFI call for example, they will cooperate and execute concurrently. That is why socket IO (like for talking to other services or databases) is so good: it naturally creates waiting/switching/yielding opportunities and does normally not lock up things.

> Best regards!
>
> Esteban A. Maringolo
>
> On Sun, Mar 14, 2021 at 3:40 PM Aaron Rosenzweig <[hidden email]> wrote:
>>
>> Hi,
>>
>> Last I checked, Seaside is single-threaded which is a “good thing.” That said, it implies that every user action must return quickly… perhaps no longer than 1 second. If the action takes longer, a chain reaction starts to form from multiple “simultaneous” users (not really at-the-same-time users, they queue up with the single thread). There are times, in apps I’ve written, where the act of clicking a link (or button) is expected to take 10 minutes (sometimes half hour). During this time we want to fork a thread to do the big task (like generate a report) that doesn’t tie up the main thread. This way we can poll every 2 seconds to ask “are you done yet?” with a progress bar and then ultimately bring the user back to the normal flow.
>>
>> Does Seaside have a pre-baked solution for this?
>>
>> If not, I’ll take Ramon’s lead as his posts are the only thing I’ve been able to find about the subject:
>> http://onsmalltalk.com/polling-for-long-running-processes
>> http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk
>>
>> In his case, he wanted a page to load immediately but then have a handful (or more) ajax requests running in the background pinging other servers to tally prices for a travel quote site. Sort of like those interlaced GIF images back in the day, his page pops with basic information then progressively renders other parts. So his example has maybe 10 threads forked for one page to fully load and shows updates inline.
>>
>> I was thinking more of one page WAProgress (I made that up) with one forked thread that monitors its execution and returns when it either completes, errors, or the user clicks a cancel link.
>>
>> These are things baked into WebObjects (NeXT / Apple) and is what my buddies and I use daily. We are tiptoeing around the idea of starting new web development projects with Smalltalk / Seaside and testing the waters.
>>
>> I’ve setup a public demo app / repo to test out these concepts:
>>
>> https://github.com/recurve/ScriptaculistPharoHeySql/
>>
>> It’s an address book application. What I’ll do is modify the delete of a contact to fork and render the Progress component and programmatically make the delete slow to show the feature. By the way, how do I do the equivalent of “Thread.sleep()” in Smalltalk?
>>
>> Thanks in advance for any advice you may have,
>> — Aaron
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside