But turning them off by default would be great IMO.
Edit: i thought the option was to disable showing error regarding the network. But the option is to disable showing any errors. I really like what @LordTermor suggested. Or an option to disable only the network errors and keeping them turned off by default would be great
I agree. Disabled makes more sense as default.
Actually that is pretty much the only error that can occur and is handled with the notification 
1 Like
Hey @philm,
Could you take over hosting mnserver? I run that service for almost 3 years now, but I’d want to decommission this server soonish…
I’d do some code cleanup and release a new version of matray pointing to the new address…
Thanks,
MO
Hey moson,
On holiday, so a bit less busy with work, so i saw this post, and maybe i can call someone in, but we need some more info:
- are you looking for hosting only?
- what’s the RAM, CPU, dusk, network utilisation?
- how many daily users?
- …
I mean: share anything you have and i might be able to ping some, one or none depending in your answers…
Hi @Fabby
thanks for your reply.
yes, hosting mnserver on a manjaro server instead of my VPS.
- RAM: ~60 MB to ~100 MB
- CPU: ~ 2% utilization (on a 4 core machine)
- Requests: I measured around 1400 requests/minute this morning. That would make ~23 per sec or about 2 million per day. Considering the default refresh time of 10 minutes in matray, that would make about 14.000 concurrent users. Since it is a Monday morning, those numbers are probably at the lower-end. Maybe 1800 r/m at peak times or so
just guessing. - Network bandwidth: Not sure because I run a mirror in parallel on that machine. Doing some maths: ~5KB per request (with default matray settings) with ~1500 requests per minute would result in about 11 GB per day.
thanks,
mo
1 Like
Works flawlessly on my manjaro gnome machine <3 thank u
Quickly scrolling to your code I can see it reads some json files in the forum, why is not the client doing that? can you describe in english what your server does and why is it needed?
I believe you’ll find all the answers here:
As to why it’s needed, well, technically I suppose it isn’t. But if nothing else, it’s damn handy. Both for notifications myself (I also subscribe to the RSS feed,) as well as for new users to stay informed of announcements.
I am asking about implementation not why someone would need desktop notifications about updates.
1 Like
well, he is somewhat right. The answer can be found there indeed 
Why is it connecting to a server application rather then parsing the RSS feed directly?
The RSS feed can be quite large (around 300 to 500 KB).
Instead of downloading this file from the Manjaro forums host on a regular basis, it fetches news from mnserver.
There’s much less data to be transferred and less burden on the forum host and client since the data is stripped down to the bare minimum.
You can see it as a middle-ware reducing the amount of data that need to be transferred.
In essence it reduces the amount of data to be transferred to each client from 500KB to 5KB. You probably don’t want to have 1400 requests per minute each sucking 500 KB from the forum host…
4 Likes
Ah, OK. This is me, shutting up, then.
There is also a API rate limit on discourse, let me discuss this with other team members, I will get back to you.
1 Like
Hey @codesardine
Any news on this?
mnserver only fetches the rss feeds every 10 minutes and I’ve never seen it being rate limited. (default rate-limit for discourse is 200 requests per minute it seems → it does not even get close to that)
@moson Since you don’t use Manjaro anymore, it seems this project will be in maintenance mode at best. I imagine you’ll still address issues and merge pull requests at least?
@Yochanan Right. I’d continue maintenance on matray itself (I see this as “feature-complete”; So bugfixes and stuff)
Just to be clear: My question is if you are willing to run the server part mnserver on your server(s).
matray relies on that service to fetch it’s data…
Looking at the source, it always returns the last n amount of data, right?
In that case response size can be reduced if the last request date is supplied.
Considering the frequency of announcements, replying with an empty 304 could cut response traffic by up to 80%, client can cache the last response.
Yepp, makes sense.
No doubt there is potential for improvement btw.
(as long as it works nobody seems to give a sh1t anyways )
Now I don’t want to turn this into a discussion about implementation details here. Please create an issue in github…
1 Like
Not yet, in my personal opinion I would say no, maintaining an extra server is extra work for what we would get in return, No one i know of in the team is familiar with GO either.
For me maybe implementing again in the new infrastructure not sure if it is worth it in my view it should be part of the software center, were in the past everything was done by different people here in the project, as loose software that does not integrate with anything else and cannot be reused or extended, now we try to do the opposite.