| ecf for client/server rcp [message #580834] |
Mon, 04 April 2005 09:07  |
Eclipse User |
|
|
|
Originally posted by: chs.tipas.at
i briefly red into the ecf paper for the eclipse con 2005.
we are using rcp as a platform for buisiness applications which are heavily
based on client/server communication, using web-services or http/native
transport for c/s communication.
as i understood it ecf is used for human to human group communication like
chat or conferencing.
is it worth to review the architecture for usage for c/s only ?
|
|
|
| Re: ecf for client/server rcp [message #580853 is a reply to message #580834] |
Tue, 05 April 2005 17:58  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Chris,
Chris Schaefer wrote:
> i briefly red into the ecf paper for the eclipse con 2005.
> we are using rcp as a platform for buisiness applications which are heavily
> based on client/server communication, using web-services or http/native
> transport for c/s communication.
> as i understood it ecf is used for human to human group communication like
> chat or conferencing.
>
> is it worth to review the architecture for usage for c/s only ?
I would say it depends upon the application needs.
If your app simply requires
1) a client occasionally making a request of a server
2) there are no 'real-time' (in the sense of user interaction) requirements
3) there are no app requirements for either direct peer-to-peer
interaction or for having clients maintain and synchronize local copies
of state
Then I would think that your application should/could just use
SOAP/XML-RPC or your other favorite RPC protocol.
If, OTOH, your app does need/require 'real-time' communication,
multipoint communication, direct client-to-client communication, or has
application state that is from one/several clients (e.g. application
sharing), then ECF can certainly help with building those apps. Of
course, it's completely possible to mix ECF with SOAP/XML-RPC for
applications that require multiple kinds of communication.
ECF isn't meant as a competitive alternative to RPC in it's different
forms (SOAP/XML-RPC, etc). It's meant primarily as a supplement to aid
the building of communications applications--which are generally not
well-supported by RPC (for reasons of scaling, performance, reliability,
needs for peer-based security, needs for less authority given to
server/peer-based applications like presence-based, file sharing
systems, data conferencing systems, other systems where clients
contribute content like RSS, shared editors, etc).
Thanks,
Scott
|
|
|
Powered by
FUDForum. Page generated in 0.03067 seconds
] 
Search
Help
Register
Login
Home
