User:Prd

10/11

Mediawiki 1.43.1 -> 1.43.5, then back to business.

10/21

Quick update, this one's gonna be extra spicy. Experimenting with Blazor, as per the C#-based local tooling for extraction, creating a connective meshing between the extractions, outputs, formatting of, server request-response and manifest management end to end. This lays the groundwork for a privatized pipeline to push new and update with respect to older manifests...eventually allowing for a pathway to achieve the same outcomes in a public manner. Once manifests can be handled to satisfaction the feature oriented development of the map will continue in earnest. Soon after will follow an API/UI refinement and mass pruning of the initially imported templates & modules as well as a general reduction in extension usage. Slash and burn remains in effect.

10/22

Manifest management pipeline underway! New site is up - concurrently building up the admin panel and app connector. In order but not particularly, construct server layer API (incoming, outgoing, on-site, server instructions), build private connection (first, then "public"), build extraction bundler, create file & zip delivery & unpacking routines... and then basically improve controls in preparation for updating the wiki's observational manager. DotNET is, in my humble opinion, a sleeping giant of a framework in the realm of web development. I'm no Java expert - and I never will be - but what the C# team have cobbled together over the years, now made more apparent by picking up Blazor (server), is downright impressive given how easy VSC is to integrate via SSH. 9 out of 10, would dev again, their docs are like swimming through a swamp - it's great.

10/23

No one would believe me and it wouldn't matter to whom it was said. There's gold in them there hills, I tell ya. I've seen it with my own eyes, I swear upon it - won't you lend your ears? What was once impossible is no longer so. Time makes a mockery of our grandest plans. I followed the river, as the trees advised, happening upon the grove of secrets. I'm not asking you to believe. Just wait and wonder.

10/25

Sometimes the best thing to do is nothing

10/26

A brief explainer of what's being assembled...

A "Manifestor" admin panel (site), such that I can intercept and manage requests - specifically speaking about token authorization for incoming manifest uploads and spot actions for adjusting data on the backend.

The Blazor API handles the site's actions, while the server itself hooks to OAuth for generating approved user tokens - this by enabling login capabilities via the app, granting wiki-sided permissions and then passing the requests on to the upload queue.

Reworking login (my own) to adhere to .NET environment practices, in preparation for setting up the public-private paradigm of the pipeline.

Due to the (seeming) ease of DB connectivity and calling thereof... some time is being spent overhauling the job runner dashboard to revisit, improve upon and expand monitoring capabilities. This in part due to the upcoming mass pruning of the wiki... which will follow the creation of the pipeline and return to feature creation (notably, unification of the manifest management) for the map.

Blazor (server) won't be rolled into the map - but Typescript will. PHP's usage will be restricted down to wiki-centric operations. There will be no further exploration of web frameworks, nor is there any need for toiling with C, Python, Go (and even C++). Instead, most needs can be met by C# - which is supplemented by the suite of standard web-server languages (HTML, CSS, JS, Typescipt, PHP, MySQL/MariaDB, Bash/Shell, systemd daemons, Nginx/Varnish, etc).

---

Update, decisions being made.

Upgrade to 1.43.5 complete. Monitoring.

SMW removed - an update from 5.1.0 to 6.0.0 would likely fix the depricated call - instead I'm opting for removal until warranted addition and experimentation with at a later point. Site feels faster? Keeping Cargo, PageForms, etc - because they have reasonable potential.

Adding OAuth to adhere to obligatory practices for establishing the secure data flow - need legitimate bearer tokens for proper authorization routine. As per analysis of AWB - works for me, works for you, whatever it takes to get us there.

More extensions will go over time. The wiki may be unstable, because I'm back to breaking things, and I can summon it from the grave whenever I please. Cloud-external backups have been running for quite some time, with both DB & total server iterations available.

Followup - fuck yeah it's faster. VROOM!

OAuth functional, consumer registered, DataTools being connected for external login purposes. Yey!

Citizen updated to latest, 3.9.0.

Updates on the DataTools delivery system, Manifestor pipeline and refinements to the wiki's special page UIs to follow.

---

10/27

It's not 2018 anymore. Better shape up!

---

10/29

If only you knew.

---

10/30

Let me show you.

---

11/1

胡​麻​を​擂​る

Nothing is out of reach.

Today I completed wiring together what is the fundamental login flow (for a C# implementation) of passing MediaWiki user credentials (through a Blazor form), acquiring conditional (as sought) authentication - permitting now secure access to be rolled out to any aspect of the server, granted by wiki via a user's existing credentials, i.e., a preliminary SSO framework.

This system, being largely transferable, is being emulated within external data tools (different request) for recreation of the authentication, additional authorization access and finally a packaged delivery mechanism for transfer to the server.

First comes the site-centric pipeline development for the already established access point.

---

11/2

Login, logout, cookie management thereof and, more broadly, handling Blazor sites in a static & interactive render modes is a lot clearer now. Because Blazor demands certain practices it can be framed as let's say "getting to 95% easy, fixing up that last 5% an excursion into modern documentation".

Focusing on the data stream, server viewer & request+result logging.

You're welcome to keep pretending it isn't so.

---

11/3

Upload, individual & manifests (bundled) tested to completion, logs (local, from the Bundler's activity and for page activity to the Manifestor's DB from the web UI, EntityFramework is awesome btw) for action tracking, failure & success, etc. The web UI, insofar as the delivery and oversight, is complete. Some further UI development to the upload form(s) - browser & viewer to make life even easier. The direct pipeline being intact means the brief hiatus from the map has ended.

Having said that - the above is a stepping stone to the one-click bundle delivery - which is mostly a matter of providing the appropriately formed OAuth request & JWT, as stated before. Due to the planned transformative effect of the 2.0 build of the map and the unifying effect of an API controller centralized to the Manifestor, JSON delivery is a first step in a means to an end - moving towards PWA & offline features, ideally.

Taking time to revisit the map features in progress, namely the overlays (embedded and imported), painting & planning tools, and player marker management. Part of that will also entail breaking down the competing CSS patterns imposed by Leaflet & Pico - both compounded by the variable/experimental style choices made in creating the various elements. Style alignment will take place especially as those aforementioned features are implemented and tested out. The wiki UI's updates (specific to the map's special pages) will unfold during those feature developments - as a return to importing & exporting data (saved markers, drawings & notes) means the planned sum of elements for affecting the map are largely settled (and the UI may then settle into a functional-usable state).

200, OK (Are you?)

---

11/4

The "hardest" part is underway. Here are the environment endpoints in play...

1. DataTools (Bundler ID & Package)
2. Caravan API (Juggling act)
3. Wiki Special Pages (UI & Controls)
4. Live Map (Data on command)
5. Blazor Web UI (Direct access)
6. Blazor & ASPNET APIs (Indirect access)

Switched into low gear to carefully scaffold identification and display (to the intermediary and controlling UIs) - with the Caravan API & Wiki UI being the requisite area for pinning down the long-term context management of the available manifests. UX and editing features are what then permit easier tagging & versioning as manifests cycle in (and supersede, not replace & remove) to the system.

---

11/5

The overall design elements for the headless CMS (of sorts) are largely mapped out. Three controllers (Auth, Ingest & Read) cover the theoretical 95%... the web UI intervenes to handle the final 5%. Migration to the database format is slotted for following feature finalization.

DataTools expanded to...

Dialogue Package

Dialogue

(Dialogue)_Lines

Feature (Locations)

Building (Locations)

Roads

Biomemap

More to do. Conceptually speaking, town layouts and landmarks. Need to make the map bigger? Need to make it load FASTER!

---

=11/6

Unsorted investigation list

Jobboard 2.0 (4)

KDB "1.0" (5)

Section 5 is where the CMS system shines. The old, pre-pipeline route was way too clunky. The upload methodology for the manifests can (and will) be replicated for finally tending to the specialized storage.

Once again lending reason for being to the approval queue - as like with packages - requested uploads for assets & mods can be a wiki-sided point of engagement - ...connecting that what is the overlay storage for the map with that of the all-encompassing secure repo. Basically following the A1<-Map<->A2<->Repo<->A3<->Wiki<->A4 (inline text is TERRIBLE for mental models, lol, you know what I mean. See the relationship matrix chart(s).)

Please review the updated package tracking - some extractions continue to be on the edge and there needs to be a final decision on the town viewer. A pop-up view should work, right? It depends on how big the map can be & how fine the zoom can be set to...

Seeker

---

Give people a chance