Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ MT-multithreading and servers » SSH package for U++ (A feature-rich ilbssh2 wrapper for Ultimate++)
Re: SSH package for U++ [message #50157 is a reply to message #50156] Thu, 09 August 2018 16:49 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13980
Registered: November 2005
Ultimate Member
Oblivion wrote on Thu, 09 August 2018 16:24
Hello Mirek,


Quote:

Sure, as I said that was the point where I decided that fully non-blocking mode is "blocking" this kind of interface.


I'm sorry but I really don't understand this one.



Well, if you are about to have such Get in the interface, you expect it to be usable with multiple streams at the same time. Storing into single ftp->done is no go then.

Really, let us wait for co_await and do it right then Smile

Quote:

If you find it reasonable, I'll rewrite the SSH package with only blocking mode in mind (but with neceasary thread safety, and add its components gradually).


"Pseudoblocking" - we still would like to have WhenWait and Abort (afaik it is now named "Cancel", but TcpSocket is using Abort, so maybe it should have the same name). WhenWait and Abort will allow GUI around it.... (That said, I think each channel should have its own WhenWait).

In reality, I do not think that there is a lot of new things to develop. This is mostly simplifying and removing.... Probaly Cmd will get simplified, ComplexCmd probably can be removed.

I have today developed SFtpStream (based on new blocking Get/Put) and tried to add a "new schema" SaveFile / LoadFile. It is a good feeling to load file over sftp line by line Smile Anyway, but supporting the standard stream, most of those specialised methods become unncessarry IMO.

Quote:

But as I already wrote in my previous messages, let us not change the "single session-multiple channels model" and not exclude any components.


Yes, after you have explained the reason, I agree. (Well, maybe it could have "private Ssh session" and both modes, but probably not worth it)

Quote:

Is this OK?


Absolutely, except I might want to work on it a bit too Smile So please at least check what happens in svn.

Mirek
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: WebSockets client in javascript connected to an U++ server sending binary messages
Next Topic: TURTLE high cpu usage, potential security flaw, and client handling problem
Goto Forum:
  


Current Time: Wed May 22 02:02:29 CEST 2024

Total time taken to generate the page: 0.02734 seconds