|
Re^3: Ideas for PerlMonks 2.0
by marto (Cardinal) on Dec 06, 2024 at 09:50 UTC
|
100% this. The only thing I'd throw into the mix would be not doing a complete port of every feature at once, rather ensure minimal viable product/functionality and add the bells and whistles later, if there's still an appetite. It'd be interesting to know how many active users make use of some of the less obvious features and customisation options.
| [reply] |
|
|
As a shot in the dark, i'm pretty sure my PageCamel framework (Perl, integrated webserver and workers, service manager, etc) would be a viable base for PM2.0. It uses PostgreSQL as a database. PageCamel is Open Source, but is also used as a base in commercial projects (internal as well as a point-of-sales system my company currently sells).
I know PageCamel is unlikely to be chosen, because it's not a "hype", "modern perl" project. But i like to take this opportunity to "advertise" my open source projects as a possibility.
It's designed to be highly extensible, integrates all kinds of features that lower manual maintenance (automated DB backups, automated PG statistics triggering). PageCamel is designed to run independant workers (that's how chatterbot and cp stats work), the user management is highly adaptable (adapting the current usergroups/permissions from PerlMonks would be a matter of a couple of hours at the most), and getting node rendering working shouldn't be too hard either.
I already use a system similar to Nodelets where different modules can "inject" data into a to-be-rendered page. PageCamel also supports multi-language, a per-user configurable font, theme support, a very configurable master data (de: "Stammdaten") editor, a WYSIWYG html editor and a lot more.
I currently don't have a discussion/threads/forum module though, but i have a lot of the required code basis to build one quickly. My rough estimate is that i could get one going with about 40 hours of work, about the same time it took me to take over the stuff from Tanktalus and implement Chatterbot.
And i certainly would be willing to put up the bulk of the work required. For free, of course. While commercial work pays my mortgage and puts food on the table, working with you folks is way more fun.
My main concerns would be to make the following things work from day one:
- Import all existing posts and User accounts from PM and make them render as correctly as possible.
- Node-IDs will continue to work as they are now and with the IDs unchanged for existing posts.
- Make sure existing external links to PM (including to specific posts) continue to work as normal.
- Integrate chat, chatterbot and stats directly into the system. This includes using the websocket and Net::Clacks support already built into my framework. This will make proper live-chatting possible and relatively easy to implement. (And yes, i would also implement proper APIs, which again, PageCamel would support rather easily).
- Improve search performance drastically by using PostgreSQL.
- Utilize existing PageCamel features like continously scrolling lists instead of paginated views for a more modern feeling and a better mobile experience.
- Provide the source code, installation instructions and a minimal test database to all pmdevs so everyone can run their own local dev system.
If there is interest, we could schedule some kind of online meeting (Discord?) where i could show how the framework works and what it can do.
The one thing that would be very helpful for a more detailed project proposal/estimate would be a database dump of the PM database (with the passwords and other sensitive information nuked, of course). That way i could start to design the PG schema and write a proof-of-concept importer for the user accounts and posts.
Conclusion: I don't forsee any insurmountable problems in porting PM from EE to the PageCamel framework. Getting "feature complete" on par with existing PerlMonks with all the bells&whistles and finetuning might take quite a bit of work (polls, XP, APIs, etc).
But getting a backwards compatible "basic" version running with all the pre-existing posts shouldn't be too hard. Replacing existing systems is sort of what the PageCamel system is designed for, after all.
| [reply] |
|
|
We should, at some point, enumerate the ways in which we want the new system (PM2) to be modern, to be "breaking".
One way, I feel strongly, is that writeup syntax should be Markdown, or perhaps better, MediaWiki#Markup.
With that given, then:
make the following things work from day one:
- Import all existing posts and User accounts from PM and make them render as correctly as possible.
- Node-IDs will continue to work as they are now and with the IDs unchanged for existing posts.
I disagree with these. The new system should start empty of content. However, it should provide an easy way to bring in PM content (posts, comments) via transclusion.
We'd be transcluding the rendered html, not the raw node source, so we wouldn't have to worry about the weird PM-specific HTML variant.
With regard to importing the user accounts: That might be a nice thing, at some point, but I would say:
- It doesn't need to have been done by Day 1. We can bring them in a little later. Could even have a way of auto-importing jdporter from here when that user registers there — optionally.
- We certainly wouldn't import all extant PM users. Maybe just those which have been active here in the last year, or something.
- Make sure existing external links to PM (including to specific posts) continue to work as normal.
Do you mean a link in PM2 node source like [id://674668] would make an external link from there to here? I address that above.
Of course, the other side of "continue to work" is that the referenced resource on PM continues to exist and be reachable.
That is something that would be out of PM2's hands. But maybe you could build in the smarts to redirect to the Wayback Machine
automatically when PM inevitably evaporates.
There has been lots and lots of discussion, over the years, of what a replacement system / PerlMonks 2.0 would, could, or should look like.
Unfortunately, it isn't particularly easy to find. Please go looking, and I will do the same.
Thank you for the good work, and thank you for volunteering!
Today's latest and greatest software contains tomorrow's zero day exploits .
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
a database dump of the PM database (with the passwords and other sensitive information nuked, of course). That way i could start to design the PG schema and write a proof-of-concept importer for the user accounts and posts.
Well, how about let's instead start with PM's MySQL schema, and understand how the tables all work and tie together. There's lots of stuff there which would not need to be duplicated in the new system.
Getting "feature complete" on par with existing PerlMonks with all the bells&whistles and finetuning might take quite a bit of work (polls, XP, APIs, etc).
Exactly. That is stuff we can add once the base system is up and running.
| [reply] |
|
|
|
|
|
|
I adore PostgreSQL, but I want to point out that AFAIK, pair.com only offers MySQL; they have very generously provided us hosting for years, and I'm not sure it would be wise to walk away from that. :/
Alex / talexb / Toronto
For a long time, I had a link in my .sig going to Groklaw. I heard that as of December 2024, this link is dead. Still, thanks to PJ for all your work, we owe you so much. RIP Groklaw -- 2003 to 2013.
| [reply] |
|
|
|
|
|
Re: Ideas for PerlMonks 2.0
by jdporter (Paladin) on Dec 10, 2024 at 22:00 UTC
|
One possible line of attack is to start with a copy of the engine being used at Everything2.
JayBonci has done a lot of incredible work over there and their engine is in many ways far better and more modern than ours.
(What I don't know is whether it is actually as modern as we would want our new system to be.)
In fact, it seems he had at one time started work on exactly this: a new PerlMonks testbed instance based on E2 code.
| [reply] |
Re: Ideas for PerlMonks 2.0
by LanX (Saint) on Dec 13, 2024 at 18:33 UTC
|
Tl;Dr
My 2 cents
From an interface perspective
...what are the "ideals" which can't be achieved by an (optional!) JS frontend? (Tobyink already did a POC)
Or a mojolicious app running on the same DB doing the rendering for users while the admin stuff remains inside Everything engine?
From a Dev perspective
... The biggest issue IMHO is that pmdevs don't have a test environment.
Considering how many things gods do are still hidden from devs, it's hard to believe that the new engine would become open source on GitHub.
From a user perspective
Making PM more appealing is not so much a question of graphical design and themes, but simplification of the interface.
| [reply] |
|
|
it's hard to believe that the new engine would become open source on GitHub
I don't see how you reach that conclusion. The problem with the PM engine is that everything is in the same tablespace, including all the privileged code and data.
We could very easily — if starting System #2 from scratch — keep the privileged code and data out of the open repo.
We could even refactor PerlMonks 1.0 so that the privileged code/data is separate, but it would be huge amount of work and probably not worth it — and far too risky without a dev system to do it on.
Today's latest and greatest software contains tomorrow's zero day exploits .
| [reply] |
|
|
Is this because the code is a "node" the same as content postings? If so, how hard would it be to do a very small refactor to separate that out? It seems to me that would unlock the possibility of a dev environment.
| [reply] |
|
|
|
|
