[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] server providers
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Mon, 17 Apr 2006 08:10:27 -0700
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 1.5 (Windows/20051201)
Tim Terlegård wrote:
There's a table with available efc container types. It lists IRC, but I
can't find any irc provider in CVS or in javadoc. It's installed in Eclipse
though. Are there license issues?
The IRC provider is available here: http://ecf1.osuosl.org. It has not
yet been approved by legal review for distribution via
dev.eclipse.org...which is why it's located at ecf1.osuosl.org. The
source for the ecf1-available plugins/apps is available via anonymous
repository path: /ecf
in CVS syntax: :pserver:anonymous@xxxxxxxxxxxxxxx:/ecf
The table doesn't say whether xmpp and irc providers are client or
servers or both. I think smack is only a client library. Maybe the
protocol column in the table should say "XMPP client"? What about the
irc provider, is it client or server or both?
Client only at this point...although ECF is moving to do more work for
servers...e.g. to support Equinox-based servers, looking to support
proxies and tunneling, etc.
I want to make a chat app, both server and client. Question is, what
provider should I choose? How much work would it be to implement an xmpp
A fair amount of work if you started from scratch, but there are OS
codebases to start from (e.g. Wildfire www.jivesoftware.org). If you do
this, please consider contributing it back to ECF.
I guess it would be much less work to make
presence/chat rooms work with the ecf generic providers?
The generic provider would serve reasonably for chat if you don't
particularly care about your clients/server interoperating 'out of the
box' with any other existing clients or servers (that is, you just want
to create your own private chat system). Note that if you prefer, you
could also implement your own client using JMS (which has a fair amount
of server lib support of course)...and/or reuse the client work (UI,
etc) that currently runs on the generic provider, but using JMS instead
(for server interoperability). What makes this possible is that the
shared object API is supported by the generic provider, JMS provider,
and the xmpp provider.
We are already providing a generic server at
ecftcp://ecf.eclipse.org:3282/server by running the generic provider as
a plugin (org.eclipse.ecf.server) and running all necessary ECF plugins
in the Equinox servlet incubator. It's running all the time here:
ECF plans include additional work to support ECF server development...so
that servers also can be created more easily via ECF/Eclipse plugins.
If you would like to work with us on this (server support in ECF), any
contributions would be most welcome.
Or would IRC be
I don't really know how difficult an IRC server would be...although I do
know there are libraries and codebases available for building IRC servers.