Joplin for Desktop
Copyright © 2016-2020 Laurent Cozic
Joplin 1.1.4 (prod, darwin)
Normally joplin has been running on 41184, but I noticed in the web clipper setting it was now running on 41186. Why this change? Is the port it's running on not reliable ? The web clipper extension wasn't working because of this change in ports, neither were my scripts that utilized the api. Is it not a standardized port each time ?
keyword: netstat ano
it's not going to help now. I restarted joplin and it took port 41184 like before. The question is wether joplin starts on the same port each time or not ? Is there a range of ports? Seems like a bad idea for a service to not keep the port. Imagine if http port 80 kept changing ...
It keeps the same port, unless the port is in use.
Wouldn't it be better if it failed or some such? Otherwise every single service relying on this API will also need to try every single port and test them before it can make use of them. It's an odd implementation choice.
Either way, I have nothing else that would be running on that port, so I suspect that Joplin itself managed to do it somehow
You don't know what you're talking about. There's a process by which you get approved via
Internet Assigned Numbers Authority (IANA). Can you run an httpd on any port you want, sure thing. But that's not what you're claiming here in this context.
Here's the story of how ssh got assigned port 22, for your amusement: The story of the SSH port is 22.
I don't know why you decided to write nonsense to fill a whole page. The point I made is that if ports shifted around, we'd never know what's running where. There's a reason for standardization around ports.
No
For information, the algorithm to find Joplin's port is not rocket science and it's the first thing documented in the API doc: https://joplinapp.org/api/#joplin-api
For information, the web clipper extension was not able to find it on port change.
I wasn't trying to imply that it was. The point is that having a service change ports unorthodox. I've never seen it done this way before, and I don't see what the problem is with questioning this. It's not like there is some religious dogma behind the implementation, is there?
I've just double checked and the clipper implements this logic, but I wonder if there's something funny going on with your setup, maybe multiple instances of the clipper server running. So the clipper finds one but not the one you expect.
I'm sorry I will work on that
I have had this same problem multiple times on Windows 10 Enterprise...
Specially when web browser has been opened before Joplin (even though the clipper has not been in use before Joplin are started... and only way to get communication up as I have found is to restart Joplin.
for me there has not been a big problem because I don't run anything else against the "api"... but it can seems that Joplin stop answering on the port in some occasions...
And Yes, I have checked that the clipper send request on the right port vs what port Joplin are using when it happens...
I have never figured out what's casing it though, ans as I say, it has never been a big deal for me...
@stolthd, if it happens again, please open the console to see if there's an error or warning: https://joplinapp.org/debugging and if you could report it on the forum or GitHub that would be great.
Yes, I will try to remember to do so...
fre. 9. okt. 2020 kl. 11:47 skrev Laurent via Joplin Forum <cozic@discoursemail.com>: