[REBOL] Thinking Rebol: WAS {Re: Re: New Rugby based chat client}
From: jasonic:panix at: 24-Sep-2001 12:02
> We Europeans are simply too far from New Zealand in provider terms (at
least
> I am). Loading the Reblet takes lots of time as well, as is logging in.
Even
> when you have async behaviour this will be annoying because of the delay
> between messages.
>
> Would be interesting to host the server in Europe as well and see what
> happens.
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