[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Rieners,
I've seen some traffic lately (and seen in the source), an indication
that Riena is working on what you seem to call 'Ridgets'. I assume
Ridget means/refers to 'Remote Widgets'. Is that correct?
I notice that the 'Ridgets' seem to have a method 'bindToModel' (and
others of course), that seem to indicate that the (local) UI widget is
being bound to (presumably) a remote model. Please let me know if this
is not a correct interpretation.
I have some questions about this architecture:
1) Does it make sense to define a new/additional hierarchy of Ridget
interfaces (e.g. IMenuButton, etc)? Won't this require use of yet
another set of UI interfaces/classes (i.e. yours) and make it
difficult/impossible for existing applications to work in a distributed
fashion?
2) Given the potential for highly variable (and unreliable) performance
of the network, isn't it questionable having the boundary between
processes defined at the UI level (Ridget)? That is, doesn't
architecture A below imply a large amount of network traffic relative to B?
Architecture A
Process 1 Process 2
Ridget (UI) -> Proxy ---> Model -> (optional UI)
compared to a replicated model approach, where a replica of the model
exists on both processes? i.e.
Architecture B
Process 1 Process 2
Ridget (UI) -> Model' ---> Model -> (optional UI)
Consider, for example, X Windows (which essentially uses architecture
A). It's not really a viable approach for anything but very high
performance/high reliability networks (e.g. LANs). Doesn't the Ridget
approach suffer from the same characteristics relative to replicated
models? Further, isn't the SWT listener listener structure (i.e. the
large number of view listeners...IMouseListener, etc., etc)
problematic? That is, for mouse moves (e.g.), in many cases won't this
result in (frequent) synchronous remote calls to update the remote
Model...and generate a large amount of traffic?
Thanks,
Scott
