> > This whole 'speed' issue has me confused. If the small Overflow objects > remain 'networked' on a sigle host (none are sent through the Internet), how > can GMS affect their speed??? Every data flow will go thru a sensor -> -> the pipenline -> -> collector (can contain a application, a internal procedure or a overflow subnet) -> -> visual (GUI or whatever). This currently goes pretty slow. Lots of IIOP traffic and memory access. I'm currently coding a benchmark plugin.. more on this later. NOTE that the collector can also read it's own data from disk, open local sockets, etc BUT it will be authenticated\controlled\bla-bla-bla. > > > And if small Overflow objects are 'networked' across the Internet, IT'S THE > INTERNET THAT WILL SLOW THEM DOWN, NOT A GMS WRAPPER. Isn't that obvious to > everone else? Hehe.. I think the concept of just using the overflow library for subnets caused some confusion :) > > As I mentioned before, I'd like to see the GUI communicate with GMS, GMS > communicate with Overflow across the Internet, and Overflow handle application > wrapping/binding and development. So, each and every GMS node is an instance > of Overflow on the Internet, which may in many cases connect to foreign > applications running on that host. > > +------------+ > | Loci GUI | > +------------+ > | > | > | > | > \|/ > +-----------+ > | GMS | > +-----------+ > / \ > / \ > INTERNET / \ INTERNET > / \ > / \ > | | > \|/ \|/ > +-----------+ +-----------+ > | GMS | | GMS | > +-----------+ +-----------+ > | | > | | > \|/ \|/ > +-----------+ +-----------+ > | Overflow | | Overflow | > +-----------+ +-----------+ > | | > | | > \|/ \|/ > +-------------+ +-------------+ > | Application | | Application | > +-------------+ +-------------+ > Fine. I will erase 'Application wrapping' of my TODO.. why was there so much email needed for this concept 8)