Questions: Would you recommend this to replace 'skyweb'?

[findel]

Hey!

I've noticed you were working on skyweb, but now you've created this fork. It appears you plan on working a bit on this. What's the current state of the library? Would you recommend this to replace skyweb?

I've had a few issues with skyweb not throwing catchable errors. Will you be implementing an 'error' event, and/or a 'disconnected' event?

Thanks, Phil

[demurgos]

Hi, I just barely finished the rewrite a few hours ago: this package is currently supporting all the features of Skyweb, except for contact-request polling. If you do not need this feature, you can replace skyweb by skype-http but I would recommend to wait a few days. The API works, but it will certainly change quickly during the next days.

I plan to spend the next few days documenting what I have done and fixing the events and error handling.

Currently, skype-http exposes a single connect function to create or restore (TODO) a connection to the Skype network. It returns a Promise for an Api object allowing you to interact with the network trough this connection. (Api extends EventEmitter)

Here are my thoughts on error handling:

• If you initiate a command trough a method of Api (ie. sendMessage or setStatus) and an error occurs and the error is specific to the command, then it will return a rejected Promise. (it will be up to you to handle it, skype-http won't throw it).
• If the error is not specific to a command (the tokens expired, connection lost, Skype is down, etc.), then I would like to try a recovery and if it fails emit a disconnected event with information.
• In case an error occurs while parsing an incoming message, I plan to throw an error event with information.

(The names might change, but I would like to distinguish between fatal errors and errors related to incoming messages)

One of my goals is to normalize then events and errors, and more specifically to associate each eventName with an eventObject interface and to do the same with errors. Basically, each distinct error.name should imply a distinct error.data interface (error messages are good for humans but if you want to recover from errors automatically, a data structure is more useful).

Still about error handling and messages, I would also like to provide a logger like npmlog to help with debugging. You could be able to set it to silent but the default would be warning or error to help us spot changes in the Skype API.

What are you thoughts about this ?

[findel]

Full disclosure; I'm fairly new to node - so I'm not up to speed of many of the best practices and so on.

Saying that, what you've said sounds great. Especially a disconnected and error event.

Regarding suggestions; I'm not in a position to suggest improvements to what you've proposed - but I do have a suggestion for a feature: allow editing of previously sent messages. I posted about this on the skyweb issues: ShyykoSerhiy/skyweb#19

[demurgos]

Ok, thank you for inspecting the trafic. I am sending a clientmessageid so it should be easy to add a editMessage(messageId, newMessage) method. (I'm just not sure how the clientmessageid is returned, but I'll definitely add it)

[MurzNN]

So https://github.com/ShyykoSerhiy/skyweb is abandoned? Will be good add link to new https://github.com/ocilo/skype-http project in https://github.com/ShyykoSerhiy/skyweb description and readme page.

[demurgos]

To be honest, both projects are not very active. I try to answer questions and merge some PRs but don't have much time to fix pending issues. I still believe that the overall design is cleaner but after using it and reading some comments, there are still issues. I am preparing an update of this library by working on some of its dependencies but I don't really know when I'll have time to actually integrate it. The two points I'd like to solve is automatic publishing to npm so I can simply give write access on Github to others and not have them relying on me, I also want to integrate schemas for the types used by the API to offer better guarantees / detect changes in the underlying Skype API. On the pure usage side, there it seems that there is a memory leak and some issues on long-running processes. The events are also not very useful. From the point of view of the library, the management of the routes is also a bit messy and errors could be more helpful.

I don't feel confident enough for the moment to openly ask people to abandon Skyweb for this library.

[MurzNN]

Thanks for detailed description, but future development and improvement will be continued and forced in skyweb or in skype-http project, or in both?

[demurgos]

The projects are now independent. I follow what happens in Skyweb and other libraries dealing with Skype, but we don't share much code anymore. In my previous message I told you the state of this library. I am unable to make predictions about the state of Skyweb.

[mitchcapper]

While skype-http does not yet have native recovery and failure handling with client code you are able to maintain reliable connections to skype for long term use. I have had a container running this project with some others in node-js for 5+ weeks now without an issue. Also memory usage is only 145M for the entire container (and as mentioned it runs some other projects as well).