|
Re^4: Ideas for PerlMonks 2.0
by cavac (Prior) on Dec 06, 2024 at 13:49 UTC
|
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] |
|
|
I'd much rather see a drop-down that lets the user select the format they were writing, and "Classic PM" would be one of the options, along with Markdown, and maybe WSYIWYG. The default would come from user settings. The database table would consist of "ContentType" and "Content", and ContentType would select the rendering module which converts it to HTML, then you cache that in a separate layer. This is how many content systems work, including Drupal.
This way you have the option to go back and re-render everything to handle new ideas for site design that depend on changes to the tags, and you leave everyone with the ability to continue to edit their posts from before the cutover.
The entirety of the rendering for old PM format should be bundled up into a module and given unit tests. It's more effort, but I strongly feel this is the "right way" to handle it.
It also lets you iterate on Markdown rendering, later. You could internally have formats like "text/markdown-2024" and "text/markdown-2027" and show them to the user as simply "Markdown" while using the specific type stored in the table to keep rendering the content with the same renderer as it was written, so that new Markdown implementations don't break historic rendering.
| [reply] |
|
|
|
|
|
|
The new system should start empty of content.
I disagree with you on that one. Sorry.
I really like the idea that PM is a continuous thing for over two decades. I'd rather spend the time to find a way to convert existing nodes as well as possible to the new markup.
This would also help with search functions and linking to old posts. Having the whole history of PM posts, with all functionality is one of the things that makes PM a great resource.
Also, the exact type of markup shouldn't be a big issue either way for most users, my focus would be on supporting a WYSIWYG editor by default.
Same goes with the existing user accounts, we should import them as is, possibly deactivating older, unused accounts, e.g. disable login but have a simple way of re-enabling on demand. This way, the usernames stay reserved for the people who come back to PM after a few years. It also preserves the history of the site. This includes monks (and their posts) who have passed away - i can't, in good conscience, just drop all that stuff and relegate it to some hard-to-find archive when we have a relatively easy way to preserve that stuff in the live system.
Do you mean a link in PM2 node source like Markup in the Monastery would make an external link from there to here?
No, i mean links from external sites to PerlMonks. Cool URIs don't change
I think this is something that is easily achieveable in my framework with a few hours of work, especially if we do import all the old posts.
| [reply] |
|
|
|
|
|
|
|
|
|
I have a few suggestions. For example, when I search the site, there should be a switch that allows me to search for part of a word or whole words only. Right now if I type in something such as "webp" if I want to look for conversation on webp processing, then it will list a bunch of results containing "webperl" and "webpage" which is not what I want. I saw no way to tell the search engine to search for whole words only.
Another suggestion: Allow people to use a predefined CSS design instead of writing your own. It's nice that some people say, "hey, you can use your own design. You can configure the site's look and feel in any shape or form," but imagine if someone does not want to spend a whole afternoon customizing his experience on PerlMonks. Let's say I want to have a cool configuation in 3 seconds. There should be a drop-down menu that offers me to choose between site designs and pick one instead of me having to do all the coding. What if I don't want to do the coding?
The site should have the ability to upload a file like a zip file containing a bigger program than just a code snippet. And the website should allow people to post pictures if they want to.
Have the ability to upload a zip file into each person's profile. For example, each person would get maybe a 100MB storage space to upload a ZIP file which might contain modules or work that the person wants to share. This again, could be searchable. You might say, "Well, there is CPAN. That's precisely what you're describing. Upload your files and it's searchable." Yes, but it's not so simple as just upload your files. There's a bunch of requirements on CPAN. Module have to be a certain way. You can't just upload any random files to CPAN.
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| [reply] |
|
|
| [reply] |
|
|
As long as the scrolling is not infinite, I prefer it very much over pagination.
| [reply] |
|
|
|
|
|
|
| [reply] |
|
|
|
|
| [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] |
|
|
Give me a few days and i'll see if i can come up with a simple mockup/proof of concept (nothing too fancy). I should be able to get a very basic forum plus a simple wiki¹ going (hey, gotta put those list of links and FAQs somewhere).
¹ i have a wiki in some project of mine, should be easy enough to pull the database schema and configs into a new project. The forum part will use the same editor and renderer, anyway
| [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] |
|
|
| [reply] |
|
|
|
|