search

munki / mwa2

Version 2 of MunkiWebAdmin
Other
156 stars 37 forks source link

Enhancement - optional re-scan time #8

Open erikng opened 8 years ago

erikng commented 8 years ago

Understandably, when changing the views, all content is re-scanned.

If there are a large amount of manifests/packages, this could take a bit of time. Perhaps rather than re-scanning between view changes, it should only occur if the last page view time has elapsed a specific time (say more than 3 minutes).

This is merely an idea. The consequence of such a change is the admin may not see the item they are looking for in between this window.

gregneagle commented 8 years ago

I assume when you say "changing the views" you mean switching from manifests to pkgsinfo or vice-versa.

I worry about doing any sort of caching -- there's so much room for BAD THINGS to happen if what is displayed doesn't match the current state of the filesystem.

Of course, on the other hand, the list never refreshes when idle, so if you switch to the manifests view and leave it idle, other people/processes could add and remove items and the web-displayed list would be inaccurate then as well.

This could possibly be addressed with a refresh timer, but with big lists of items, if no-one else is changing them, now periodically you get to wait for a refresh that doesn't actually change anything!

As long as MunkiWebAdmin2 must live alongside other methods of managing/changing a repo, this will be a hard problem.

erikng commented 8 years ago

Of course, on the other hand, the list never refreshes when idle, so if you switch to the manifests view and leave it idle, other people/processes could add and remove items and the web-displayed list would be inaccurate then as well.

This could possibly be addressed with a refresh timer, but with big lists of items, if no-one else is changing them, now periodically you get to wait for a refresh that doesn't actually change anything!

Agreed. I was also thinking about an automatic refresh time, but that could be dangerous if you are mid-edit as well.

Definitely a difficult issue to "address". There are many consequences either way.

kcrawford commented 8 years ago

If the repo is in git, git hooks could be used to keep the cache up to date.

Perhaps offer a command line tool to refresh the cache so people could implement their own method of keeping the cache up-to-date.

So something external like a git hook triggers mwacli --update-cache, which sends a notification to browser clients to refresh.

In any case, I think clients would need to be polling or have an open websocket.

gregneagle commented 8 years ago

I have absolutely no idea what any of this means, so it's very unlikely you'd see any sort of implementation from me...