|
| Re: Collaboration Server Maturity [message #582142 is a reply to message #582111] |
Thu, 16 June 2005 23:05  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Scott,
Thanks for the feedback.
Scott Dybiec wrote:
> Hey, ECF is pretty cool. Within a couple days work I got it integrated
> with my RCP application --- both the client chat stuff and an embedded
> collaboration server. I attached a screenshot.
Thanks much for the shot. Would you be willing to consider contributing
this client as an example ECF application and distribut under the EPL?
>
> I started multi-user testing of the system and ran into issues. I'm
> using the "Generic" server, not the XMPP server. The chat seems to work
> reliably over fast connections. Not quite as forgiving over wireless
> cell connections.
Yes. The default timeout was set (by me) to 10seconds. Given the need
to ping at 2x that value this timeout is generally going to be too short
for less reliable transports (like wireless).
You can reset the timeout for both the client and the server to
something larger (I've since reset the checked in defaults to 30
seconds). For the client and the server run from within Eclipse, these
values are set as parameters to the containerFactory extension. See the
plugin.xml in the org.eclipse.ecf.provider plugin. Look for the
'defaultargument' element in this plugin.xml and you will find it.
If you are using the standalone server (i.e. run from the java command
line), see the server config file in
org.eclipse.ecf.server-feature/conf/server.xml.
And, like I said, I changed the default in all these locations to
30000ms so things would be a little more forgiving 'out of the box'.
You can get all these changes if you update from the ECF CVS modules.
>
> The file transfer hangs and subsequently times out, especially for the
> person-to-person transfers (Send File to Joe Blow...) vs. the group
> transfers (Send file...).
This is very likely due at least partially to the timeout problems above.
>
> What are the maturity levels of the collaboration servers, generic vs.
> XMPP? Should I be using an XMPP implementation instead? Which one would
> you recommend for embedding in an RCP application?
The generic server is (admittedly) not yet mature. One of the things
that we are doing right now is trying to get some server resources in
order to test the generic server and find bugs, fix them, and generally
improve the generic server's reliability and performance.
If you need to go to production very soon then I would suggest either
using an XMPP server implementation for your app (and perhaps we can
work together in adding support for the XMPP multi-user chat, which is
not yet in place) OR helping us test and mature the generic server.
Although it's admittedly not mature, it's not going to be a long road to
get to greater maturity IMHO.
>
> Thanks for the great work on this.
Thank you for the kind words and the usage. If I can speak for the team
a little here...although things are progressing more slowly than we
would like, we are continuing to work on this as much as possible...and
would like to support usage by folks such as yourselves. It's still
very early for this project, though, and we know that things need to mature.
>
> As an aside the ECF-to-RCP integration efforts were largely around
> classpath issues. Part of the price for the excellent separation of
> concerns enforced by the Eclipse plugin model.
Yes. We've been working some with the equinox team on the classpath
issues (particularly around serialization/deserialization) and the OSGI
runtime. Specifically, in the recent version of the OSGI runtime they
added the concept of a 'buddy loader', which will allow us (and other
plugins) to specify at plugin creation time what other classes will be
needed for things like deserialization. We (ECF) have not yet
incorporated this into our own plugins, but it is something that we will
be taking advantage of. This should ease some of the
classpath/classloader issues you experienced, as it allows the
specification of inter-plugin class relationship only resolved at
runtime (as opposed to compile time).
So, in any event, I think the message is that life will be better
soon...with 3.1 release this buddy loader mechanism will be officially
'out' and hopefully by that time (next week approx) I think we may have
ECF using the buddy loader mechanisms.
Thanks again for your comments. All reports of usage and interest will
be appreciated...AND such comments (made to this forum or elsewhere)
will be VERY helpful for us in finding additional resources for doing
testing, providing server resources for the community to use (we would
like to make a number of ECF generic servers and xmpp servers available
for usage by interested developers...is this something people would
benefit from?).
Thanks,
Scott
>
> $cott
>
> ------------------------------------------------------------ ------------
>
|
|
|
Powered by
FUDForum. Page generated in 0.02878 seconds
] 
Search
Help
Register
Login
Home
