Thinking Rebol: WAS {Re: Re: New Rugby based chat client}

least

Even

hmm.. interesting. What is the precise delay.? How did you track it [traceroute]? What kind of arrangement of servers would make this fly? It seems that Rebol and the indicated IOS applications must all depend to some degree on addressing these issues. Designing applications that tend to just-in-time instead of real-time or near-real-time. I thought that Rebel was created partly to provide a low-profile platform for implementing all this. But the impression I am getting is that the same basic problems exist. ie local Client processor performance now far outstrips network latency issues, and heavyweight servers seem to be an essential part of the solution. Am I reading this all wrong? I hope so... My hope is that good topology and fast local applets which combine server+client ubiquitously can work brilliantly. At least when communications are among relatively small groups of people sending relatively small amounts of data and meta-data. ClientServer combos can maximize use of metadata. I believe much net communication is among small groups of people most of the time, often only a handful or less at any time. This is the nature of real workflow. I hope all this does not sound to vague. I am a multimedia develop not a network engineer, but my observations are mostly based on r&d design consulting for past 5 years with European businesses. Most projects involved clients who expressed a need to develop collaborative business workspaces over internet. But usually with they had little or no hands-on awareness of the web or internet habits. Just addressing workflow and getting them past the widely publicized paradigms of internet = THE WEB + email was first problem. Second problem was lack of toolkits for rapid prototyping of Internet based applications so we could all start playing with their problem to focus on the real workflow needs. The CEOs and project managers almost all argued they wanted well-defined heavy top-down solutions before even had even really experienced themselves hands on what we were talking about. Years of expensive software development contracted out to database consultants had convinced them that nothing small or cheap or non-MS could be much good.. Rebol would seem to be an ideal platform for rapid prototyping, and its longer-term follow up implementation. Rebol/View offers a wonderful brevity to smart module desktop net apps. I am asking everyone here for broad design wisdom for using Rebol in distributed applications. [vaguely, but sincerely :-)] What the limitations are..? What the advantages are..? What would a Rebster look like? Do we have the pieces now ? If it we want to use Rebol for sharing graphics, calendars, whiteboards and PDFs among restricted, trusted groups of users [<25 say, typically 5 -10 people] what would you recommend for system specs and architecture? Is it still way too early to have this discussion.. come back in 2002 after much more trial'n'success? When can we publish the book: "Thinking Rebol" hope this makes some sense.. thanks - Jason