Implement something close to w3c API about emacs-websocket

[ahyatt]

Closed with latest commit. There are still a few divergences with the w3c API, notably that I'm passing frames back to on-message instead of raw text (I think my way is the right way), and I haven't implemented "bufferedAmount" (I don't know how yet).

[tkf]

Wow, now websocket.el speaks RFC6455 and has W3C-like API! This is great.

Now the API is renewed, I guess it is good time to add a version number to websocket.el. Do you have any plan to do that?

[ahyatt]

Soon. I want to support extensions first, and improve the documentation.

Are you using this for a project? I'd love to have a real-world user before
declaring that it works by giving it a version number.
On Jun 1, 2012 6:40 AM, "Takafumi Arakaki" <
[email protected]>
wrote:

Wow, now websocket.el speaks RFC6455 and has W3C-like API! This is great.

Now the API is renewed, I guess it is good time to add a version number to
websocket.el. Do you have any plan to do that?

---

Reply to this email directly or view it on GitHub:
#11 (comment)

[tkf]

Good to hear that!

I am using websocket.el for my Emacs IPython Notebook client:
https://github.com/tkf/emacs-ipython-notebook
Without websocket.el my project does not exist. I haven't tried the new protocol and API but I will do it soon.

[ahyatt]

Let me know when you've tried it. I think I've made all the changes I
want to make, unless I decide to implement wss. So I just need
confirmation from you that the current version works, and I'll label
it 1.0.

On Fri, Jun 1, 2012 at 7:24 AM, Takafumi Arakaki
[email protected]
wrote:

Good to hear that!

I am using websocket.el for my Emacs IPython Notebook client:
https://github.com/tkf/emacs-ipython-notebook
Without websocket.el my project does not exist.  I haven't tried the new protocol and API but I will do it soon.

---

Reply to this email directly or view it on GitHub:
#11 (comment)

[tkf]

I switched to the new API a few days ago and I have no websocket problem since then.

[ahyatt]

Awesome!
On Jun 6, 2012 7:40 AM, "Takafumi Arakaki" <
[email protected]>
wrote:

I switched to the new API a few days ago and I have no websocket problem
since then.

---

Reply to this email directly or view it on GitHub:
#11 (comment)

[tkf]

Anything you plan to do before the release? :)

[ahyatt]

Just saw this comment. The README has some explanation now of what should happen before a 1.0 release. I'm also thinking of switching the API to be based off of eieio, which needs to either happen or not before 1.0. There's a branch that may or may not work I just created, and will be working on in the next few days or weeks.

[tkf]

Yea, I saw your branch. Does it mean you are planning to support server also (Maybe not for 1.0, like 2.0)? Running websocket server in Emacs would be really cool. For example, this package use websocket server (in Node.js) to preview any stuff in browser https://github.com/yukihr/Warp. When you scroll Emacs buffer, preview in browser move along with it. This is very nice. I guess websocket.el can help this kind of package.

EIEIO is nice, but I found EIEIO does not work well with Emacs documenting system, such as describe-function. You can define multiple methods with same name but only one docstring shows up when you use describe-function. To see all docstring, you need to use describe-generic. Also, argument information when using describe-function is useless (it shows just &rest LOCAL-ARGS). I guess this can be drawback when providing a public API. But maybe mentioning about describe-generic in README is enough. Anyway, this is the only drawback I've found when using EIEIO. Probably you already know all of this. I am just mentioning it because I'd want know before using it.

[ahyatt]

Supporting server is probably something past 1.0. Shouldn't be too difficult, though, since it's just some wrapper code around functions I already have.

The eieio branch is interestin, since it solves the problem of users storing data much more elegantly, since they can create their own defclass that has the slots they want, inheriting from websocket. On the other hand, eieio is another dependency I'm loath to introduce, and most elisp hackers don't use it. So, I'm still thinking about it... let me know if you have any further opinion on if the eieio would provide a better API for you or not.

[tkf]

If EIEIO is just for additional slot, defstruct already solved the problem because it allows inheritance, if I remember correctly. EIEIO's strong point is that you can extend/override methods and you can do dispatching based on types. I don't know if it helps providing cool APIs. You already implemented w3c-like API and it was enough for me.