Lukas, For GemStone, the split in OB was made such that the #changed messages are sent across the wire with Morphic running on the client (local) side. The Morphic requests for lists were then made back across the wire and so on ...
There is still a fair amount of traffic that is probably unnecessary, but I think that with some focussed work, the number of round trips can be reduced even more.... For a particular window like the debugger, it might be possible to tighten things up even more ... for the debugger we'd need to blow the dust off of the OB debugger:) I would be willing to share the work on something like this for Pharo...it's not at the top of my priority list right now, but it is near the top, so I'd be willing to work with someone else to share the load ... Dale ----- "Lukas Renggli" <[email protected]> wrote: | On 13 May 2010 17:51, Igor Stasenko <[email protected]> wrote: | > On 13 May 2010 14:46, Geoffroy Couprie <[email protected]> | wrote: | >> Hello, | >> | >> On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <[email protected]> | wrote: | >>> On 13 May 2010 02:22, Torsten Bergmann <[email protected]> wrote: | >>>> Why dont you use the VNC facility of Pharo which is | >>>> typically used to administrate Seaside images: | >>>> | >>>> http://book.seaside.st/book/advanced/deployment/maintaining/vnc | >>>> | >>>> Just install the RFB package, configure and use a normal | >>>> VNC client to remotely use and drive the image. | >>>> | >>>> So you have workspaces, debuggers, you name it, ... | >>>> | >>> Remote debugging is a must. Headless, no UI. | >>> Remote debugger can create own UI at debugger side, while | debugged | >>> image could be quite small, | >>> contain no UI, Morphic & rest of stuff. | >>> | >>> Think of debugging a kernel images, where you can't afford having | a | >>> lot of stuff loaded, not saying about RFB. | >>> | >> | >> I like the idea of a headless image :) | >> | >> I don't know how hard it would be to add a remote debugger. Could | it | >> be done by catching the exceptions on the remote side and sending | >> commands like walking the stack from the local side? | >> | >> For remote administration, it would be fairly easy to have a local | UI | >> sending commands periodically to remote VMs to ask for status, | execute | >> some code, etc. | >> | > | > It should be a relatively easy. | > A debuggee should need is to encapsulate the objects by some ids, | > and then transfer these objects printstrings over a connection, so | > debugger could show them. | > The debugger consists of a number of panes - 2 inspectors and code. | > So, if you implement a remote inspector, you'll have about 40% of | job done. | | You could also implement a new view for OB: meaning the model of OB | runs on the server while the view is on the client. AFAIK this is | what | GemStone does for its tools in Pharo. I guess that approach could be | adapted to also work between two Pharo images. | | Lukas | | | | > | > | >> Best regards, | >> | >> Geoffroy | >> | >> _______________________________________________ | >> Pharo-project mailing list | >> [email protected] | >> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > | > | > -- | > Best regards, | > Igor Stasenko AKA sig. | > | > _______________________________________________ | > Pharo-project mailing list | > [email protected] | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | | | | -- | Lukas Renggli | www.lukas-renggli.ch | | _______________________________________________ | Pharo-project mailing list | [email protected] | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
