search

candy-chat / candy

JavaScript-based multi-user chat client for XMPP.
http://candy-chat.github.io/candy
MIT License
1.32k stars 370 forks source link

Please provide demo deployment #466

Closed andrey-utkin closed 7 years ago

andrey-utkin commented 8 years ago

It would be very handy if you provided demo mode so that anybody could use your webapp deployment to login to their own XMPP account on any XMPP server, just using their WebSocket or BOSH URL. Just like e.g. https://tryit.jssip.net or https://legastero.github.io/jingle-interop-demos/stanzaio/

Thanks.

jdc20181 commented 7 years ago

Hi!

There is a demo.
http://candy-chat.github.io/candy/ Just click the big "Try the Demo" button.

andrey-utkin commented 7 years ago

Thanks for this, but this is very far from what was requested. In my perception, Candy does everything on client side, so it mustn't be bound to some special server governed by deployer, so it should be straightforward to let user to specify server and user credentials they want. This kind of demo would be much more useful and engaging.

Also, fitting demo interface into small window area cripples usability, it would better be standalone.

jdc20181 commented 7 years ago

That wouldn't be 100% possible. I mean the demo they currently have allows you to enter a username but it also doesn't store anything from what I can tell.

Let me see if I can find a unofficial Demo.

jdc20181 commented 7 years ago

The reason why they can't do what you are asking is they have to use a external provider just to allow us to see the demo - GH-Pages is what they use for thier website, and GH pages is Static meaning PHP and other languages as well as Databases aren't supported directly to gh pages.

Its not my place to say, but as a Deveoper myself, I would say it probally won't happen.

andrey-utkin commented 7 years ago

I am not aware to be honest, but according to GH stats in this project there's no PHP. Also there's no technical need in web backend for web-based XMPP client, check https://www.jsxc.org/example/ or the link from original post.

jdc20181 commented 7 years ago

I was using that as example. Many server side languages aren't compilable. There is probably many reasons. If I can later I will see what I can do.

What you could do is Fork and create your own. I mean. It would be hard for them to make everything so we can see a demo- but I also agree there needs to be a better demo.

Maybe try a google search?

(My hopes is to get someone else to give an official answer) as in not a project contributor who makes any decisions. I'm just trying to answer simple questions.

Let me get back to you later- for more reasons why they use the external host.

On Thu, Dec 1, 2016 at 4:58 PM Andrey Utkin notifications@github.com wrote:

I am not aware to be honest, but according to GH stats in this project there's no PHP. Also there's no technical need in web backend for web-based XMPP client, check https://www.jsxc.org/example/ or the link from original post.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/candy-chat/candy/issues/466#issuecomment-264308365, or mute the thread https://github.com/notifications/unsubscribe-auth/AMphBgci3TGK0Ewc-lltmuJ7SKsw4cEqks5rD0L5gaJpZM4Htreu .

mweibel commented 7 years ago

While I'm an original project lead and the demo still runs on my host, I'm not a project maintainer anymore, so take my answer with a grain of salt ;) We host a demo and you can use it to test how Candy works without plugins installed. Hosting a demo which allows you to connect to any XMPP server comes with a lot of administration overhead (preventing abuse is one of the problems) and doing so for free is something I didn't want to do. Additionally, because it all goes over websockets or BOSH, the XMPP server in question needs to have such an interface. If it goes over BOSH especially this means allowing the origin Host to connect to that interface with a pre-flight OPTIONS request. Otherwise a local proxy to any possible server would need to be implemented which also can mean (depending on the amount of concurrently connected users) a lot of additional overhead. The goal of the demo is simple: show that it works and how it looks. A more elaborate demo would mean that some users might not want to setup Candy on their own host because it's more convenient to just point their end users to that demo. Which essentially would mean using resources the Candy project maintainers provide and pay for, for free.

I'm not sure what the goal of your request is. What would you like to test which the current demo can't provide?

andrey-utkin commented 7 years ago

Hosting a demo which allows you to connect to any XMPP server comes with a lot of administration overhead

I don't see what you mean.

(preventing abuse is one of the problems)

It's not Candy maints problem as long as what they provide is simply static web page with JS which directly connects to XMPP server. You're not going to receive DDoS because of this.

because it all goes over websockets or BOSH, the XMPP server in question needs to have such an interface.

Sure, BOSH or websocket interface is a prerequisite on XMPP server's side. Not Candy maints concern again.

Which essentially would mean using resources the Candy project maintainers provide and pay for, for free.

I didn't know Candy maints pay for static website on GitHub pages.

I'm not sure what the goal of your request is. What would you like to test which the current demo can't provide?

To allow user to use his existing XMPP account and contacts. If that's not the purpose of Candy - I'm sorry and I'm out, I was creating similar feature requests to multiple XMPP web interface projects at same time.

benlangfeld commented 7 years ago

To allow user to use his existing XMPP account and contacts.

That's not the purpose of the demo. It's a demonstration of the project, not a hosted service. You are welcome to set up your own Candy-based service wherever you like and customise it to your preferences.