Wedge
Public area => The Pub => Features => Discussion démarrée par: dorje le 20 Avril 2011 à 16:11
-
I don't know if this is the correct section, since at actual developement state this thread is more a suggestion request. :)
So, I'm planning to write a chat client that is *inexpensive* for the server running wedge. Inexpensive, that means ideal for forums that are executed on a shared hosting server. :) The system in my mind is very simple: I defined a simple protocol - something like:
[id_member_from:id_member_to:time]hello! :)
where id_member_to can be * for messages dedicated to all chat members and a valid ID for something like IRC query.
The only thing I need now is a free service that in some way can accept requests and store such formatted strings. So the entire system will be done in javascript, with load only on the client side.
What suggestion I need? Well... I only wanted to know if someone knows for such a free service around on the web. :)
-
The big factor is whether or not authentication is required for visibility. If it's not, there's a variety of things that might be suitable that can be just thrown in.
But if authentication is required, roundtrips to the server are inevitable.
-
But if authentication is required, roundtrips to the server are inevitable.
-
Well, it's still going to be via a server one way or another... unless you can figure out how to do peer to peer communication in a browser in JS (which doesn't work unless both sides are configured to receive HTTP requests)
-
Well, it's still going to be via a server one way or another... unless you can figure out how to do peer to peer communication in a browser in JS (which doesn't work unless both sides are configured to receive HTTP requests)
-
There are so many problems that can be made through such a third party hosting; you're entirely relying on that third party never to change their API, authentication mechanism and so on, and it's particularly vulnerable because you'd have to supply the third party credentials to the Javascript which would have to live in the page all the time to keep requesting from the third party. Plus I can't think of a single non chat service that this wouldn't violate the TOS of.
-
you're entirely relying on that third party never to change their API,
And that's the simpliest of APIs :lol:
-
That happens when they think that bugs justify changing the entire code of an API...
-
Now why does that sound familiar?
-
Now why does that sound familiar?
-
Well, it sounds like the time twitter start using other protocols for their API.
-
There are so many problems that can be made through such a third party hosting; you're entirely relying on that third party never to change their API, authentication mechanism and so on, and it's particularly vulnerable because you'd have to supply the third party credentials to the Javascript which would have to live in the page all the time to keep requesting from the third party.
Plus I can't think of a single non chat service that this wouldn't violate the TOS of.
Ok, the project is in standby now: waiting the illumination! :thanks:
-
Pastebin? So your solution to a potentially changing third-party API is to use another third party?
-
No: to use a third party API that is relatively stable and very simple. :)
But nevermind, the TOS are very clear about not using pastebin that way...
-
That's the thing: I've never used pastebin... only breezed through it once half a year ago.
-
Well, it's still going to be via a server one way or another... unless you can figure out how to do peer to peer communication in a browser in JS (which doesn't work unless both sides are configured to receive HTTP requests)
http://labs.adobe.com/technologies/cirrus/
-
Well, yes, it's fully peer to peer by Cirrus 2... but it requires Flash. If that works for you...
-
If it requires flash all I know that it's going to be a major PITA.
-
Steve just friended you on FB. :)