What is Candy?

[benlangfeld]

In planning for changes to come to Candy, it's important I think for us all to fully understand what Candy wants to be, what the project is trying to achieve and what use-cases we support.

Background

From http://candy-chat.github.io/candy:

There are plenty of web-based chat clients out there. Most of them are built to emulate your instant messenger. They offer you tons of settings. They can join multiple networks, let you edit your profile, and even manage your message history. Candy is different. It's built for your community.

and

Why Candy?

• Focused on real-time multi-user chatting → Screenshot & Demo
• Easy to configure, easy to run, easy to use → Setup & Usage
• Highly customizable → Plugins & Event Hooks
• 100% well-documented JavaScript source code → API Documentation
• Built for XMPP (Jabber), using famous technologies → Under The Hood
• Used and approved in a productive environment with up to 400 concurrent users → About Candy
• Works with all major web browsers including IE7

Some discussion at https://github.com/candy-chat/candy/issues/207:

And finally, I think locking IM behavior on the assumption that "Candy is a MUC client" is truly sad :( XMPP is an onion, and the core is IM. MUC is "only" an extension. Even if you don't want to bother with user roster and stuff, I would be glad if while refactoring the whole thing, you would keep that in mind and make some room for the do-gooder that would implement it on Candy :) Sure, I'm not against sticking to the standard way. What we're do with Candy is a lightweight MUC client for XMPP. Lightweight is the key: we don't want and can't support every possible use case one could think of. Don't get me wrong: I like XMPP and it's extensibility, what I don't like is pretty much every client out there (because they try to handle everything and usually with a bad user interface). In order to build a lightweight MUC client we have to do some compromises to keep the code manageable.

With the current codebase however, it's hard to improve it in various ways. The optimal thing for me would be to have a common use case (the one which is implemented right now) but if anyone needs to change it in certain ways, he can change the behaviour using the API (read: events) we provide. This, however, is not so easy because of the current codebase.

Relative positioning

Other Javascript XMPP clients include:

• Converse
• Kaiwa

Converse is intended to be separate from any service, permitting connection to any network; the opposite of the statement on the Candy website and the general trend towards specific clients for specific services. Kaiwa is much more similar to Candy, with a bunch of features that Candy lacks, but based on Backbone and some &yet specifics (HumanView, etc) without any focus on customisation/extensibility.

Candy's current upside is that it intends to be extensible with a plugin system and customisable in terms of theming. The downside is that both of these are difficult, brittle, and don't scale well; this is partly because Candy

Potential statements of Candy's purpose

Some candidate statements, without being dressed up, might be:

• Candy is what it is; suck it up or use something else; or
• Candy is intended to be extensible and customisable.

Further:

• Candy is a lightweight MUC client. It rejects many features (1 on 1 chat, voice/video calling, etc) on the grounds of complexity.
• Candy is an open-source equivalent to Slack, HipChat, Campfire, etc. Extensibility is not important; customisation is done by forking or feature flags.
• Candy is a toolkit for building chat clients; the view is the whole point, but as individual components that can be composed into a complete application.
• Candy is a toolkit for building chat clients; something higher level than Strophe, but where the View layer not important.

These of course might be composed.

I'd love to hear everyone's thoughts on what Candy is to them, what Candy should be and how it might be differentiated from other similar projects. If we can decide this, we can properly allocate effort to work that will advance a goal, rather than starting from either implementation fantasies or narrow resolutions to specific issues.

[lpradovera]

On the grounds that anything with a View layer is never going to be used without customization, I would look into separating Candy into a toolkit and a vanilla UI implementation, essentially supposed to be extended via fork. The toolkit would instead be intended to be used as is.

[terraboops]

Everything you stated is definitely in line with what Candy is to me (and my use case).

For me (and I hear similar woes in this issue forum) Candy was a real pain to customise -- because the View layer was not modular enough to be monkey-patched effectively. Extension points seem to exist by coincidence rather than design. IMHO, this is the main pain point. It's also the main selling point, at first glance Candy does appear to be quite customisable -- especially when compared to the other XMPP Web Chat libraries. It's only when you really sink your teeth in that you come into some tough-to-solve problems.

[terraboops]

I guess I'll add a bit about my specific use case. Basically, I work on a real-time web application where students interact in a classroom-like environment online.

With Candy, students can easily communicate to each other and their instructor inside the virtual classroom. Candy is integrated into the application as a small pop-up in the bottom right corner of the screen, which is themed with the customer's brand colours.

Not sure if this is a typical use case, but I chose Candy after seeing some of the examples in the Wiki's "in the Wild" section: https://github.com/candy-chat/candy/wiki/Candy-In-The-Wild

Seems like most of those interfaces would have been quite cumbersome to cobble together! Especially the one where it's integrated into a game -- not really sure how they did that.

[benlangfeld]

Could you perhaps include some screenshots of that implementation so we can understand the extent of your customisation, @tylermauthe?

[terraboops]

Probably, I'll find out if it's okay to share.