(Followups to squeak-dev, please.) Hi all-- Ben writes: > It would be amazing to run Cog in a web browser, and thus facilitate > all our favourite Smalltalk dialects. Until WebAssembly has the stack introspection that Clément mentioned, I think the in-browser remote display of Snowglobe[1] would be a good alternative. Even after that, there are good use cases, just like there are uses for VNC, etc. Snowglobe does that sort of screen-sharing in a more convenient way ("just visit a webpage"), and supports distributed computation. The user could approve a JavaScript bridge between the remote app and their web browser, in addition to traditional remote Smalltalk messaging. Even just having a web browser as a launcher for local Cog systems is useful (similar to the launchers of Parallels, VMWare, Kitematic for Docker, EC2, Cloud9, etc. etc.), and it can be a convenient UI medium too. > Side thought: Craig's work to incrementally download a running image > could be useful to reducing web page startup time. Ooh, I'm not sure I did what you think I did... Tell me more about that feature! :) So far there's still a point where an entire snapshot has to transmit, but you can keep using the app remotely in the meantime. In many scenarios you just don't notice the download and subsequent switch to local native Squeak. > Hard to find info on Snowglobe. Only 4 million results to compete > with. When I add "smalltalk" or "squeak", I get [1] within the first five hits on Google and DuckDuckGo ("snowglobe smalltalk" is first on Google). Is that good enough? Speaking of Squeak, Snowglobe isn't limited to that. It just needs WebSockets support, which is in all the Smalltalks and web browsers now. > I tried the demo. http://blackpagedigital.com/snowglobe > Pretty impressive. Thanks! > The world menu is a bit sluggish for a few seconds to pop up each > time... Hm, I just played with it from Europe and it seemed fine. (There are two Snowglobe app servers at the moment, in California and Germany. Amazon's DNS chooses the one with the least latency for you.) I had to restart the California server. What's your region? Like all app streaming systems, performance is sensitive to end-to-end network latency. For some lag-intolerant things, like displaying the normal mouse cursor as you move it around, the local SqueakJS takes over. It looks like I should do the initial display of some of the menus similarly. > ...but menu item highlighting is instantaneous, as is editing in the > system Browser. However mouse point is off by about 15mm at 7o'clock > position. Platform is 32-bit Linux Chrome Version > 48.0.2564.116. (I guess any further discussion on this would be > better on squeak-dev) Ah, that bug's new to me. Yes, let's move discussion of that to squeak-dev. For direct contact I'm on the Squeak Slack channels[2], Twitter (@ccrraaiigg), Skype, etc. etc. I think Slack would be best for getting a live group chat going. > ...reading about "live serialization" the term "serialivation" pops > in mind. Hm, that could lead to libation or Live Nation, or even Disassociated Press[3]. (Search engines are going to love this message.) Phil writes: > Snowglobe is nice indeed. But still slow on this monster of a machine > of mine. Hm, I suspect either the local SqueakJS didn't actually connect to an app server, and you were just observing local SqueakJS UI performance, or there was severe network latency somewhere between you and the servers. I'd be happy to look at it with you. > There is also this: http://blackpagedigital.com/tether > > UI page appears dead though. Oops, some stale links under the hood on that page. Anyway, that demo is superceded by the content at [4], which is what you get when you visit /tether now, too. Thanks for checking it out! -C [1] https://thiscontext.com/2016/10/31/app-streaming-with-snowglobe [2] http://squeak.slack.com [3] https://en.wikipedia.org/wiki/Dissociated_press [4] http://blackpagedigital.com/squeak -- Craig Latta Black Page Digital Amsterdam | San Francisco [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
>> Side thought: Craig's work to incrementally download a running image
>> could be useful to reducing web page startup time. > > Ooh, I'm not sure I did what you think I did... Tell me more about > that feature! :) So far there's still a point where an entire snapshot > has to transmit, but you can keep using the app remotely in the > meantime. In many scenarios you just don't notice the download and > subsequent switch to local native Squeak. Hey Craig, I'm guessing the user would have to indicate when they want to download the snapshot right? The object memory is always changing, if they continued using the remote connection then the transmitted snapshot would be behind the work the user did via the remote connection during the download period..? |
Hi Chris-- > I'm guessing the user [in the transition of an app session from > remote to local] would have to indicate when they want to download > the snapshot right? The object memory is always changing, if they > continued using the remote connection then the transmitted snapshot > would be behind the work the user did via the remote connection > during the download period..? I think we can finesse that, by synchronizing the remote and local instances of the app before the remote one pauses. I use "pause" in the sense of pausing a movie, distinct from system snapshot. In the current design (for a future release), the canvas displaying the app is decorated with control widgets, similar to a YouTube video. In addition to typical controls like play and pause, there's a button for moving the session to the local machine. After the snapshot, download, and local resumption, there are two live instances of the app. Using Tether remote messaging and the Naiad module system, they can synchronize themselves. There are other possibilities, too. For example, the remote and local instances could continue running together, as a distributed app. thanks, -C -- Craig Latta Black Page Digital Amsterdam :: San Francisco [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
In reply to this post by Craig Latta
On Sat, Dec 10, 2016 at 12:26 PM, Craig Latta <[hidden email]> wrote:
Your imprinting technique... To run an imprinting-web-app, initially a very small minimal Image knowing just enough to display the initial menus is downloaded, then additional functionality streams down as needed depending on menu item selected. The full app could continue to download, but priority would be given to anything associated with the selected menu item. cheers -ben cheers -ben
|
Free forum by Nabble | Edit this page |