Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^5: Current posting ability limitations (interim)

by cavac (Deacon)
on Dec 10, 2011 at 09:59 UTC ( #942778=note: print w/replies, xml ) Need Help??

in reply to Re^4: Current posting ability limitations (interim)
in thread Current posting ability limitations

I certainly would be interested in getting my hands on the PM code. Mostly for personal reasons: I'm wondering how much work it would actually be to convert all the PM data into a modern database layout with completly new, modernized codebase.

For the last couple of months i have been thinking about that problem. Seems like a lot of work. But what i really want to know: Is it actually possible? Would i be able to do it? I bet i can, but i have to prove it (to myself, mostly).

You now, "never set your goals to low" and that stuff ;-)

Don't use '#ff0000':
use Acme::AutoColor; my $redcolor = RED();
All colors subject to change without notice.
  • Comment on Re^5: Current posting ability limitations (interim)

Replies are listed 'Best First'.
Re^6: Current posting ability limitations (interim)
by jdporter (Canon) on Dec 12, 2011 at 16:29 UTC

    Your intuition is correct: it would be a lot of work. But I have some observations to offer you which I believe should add some perspective on the problem:

    One one hand, the database schema of user-posted nodes is relatively clean and straightforward. If you wanted to create an entirely new site without necessarily any feature compatility with this one, but with a starting nodebase of PerlMonks' existing user-posted nodes, you could conceivably do that without much work, I think. (Issues of user accounts and node ownership aside.)

    On the other hand, if your intent was to re-implement the functional features of PerlMonks, more or less, you'd face a prodigious amount of work. And there is a certain terra incognita of features available only to the gods which, unless you got one of them to join in your project, you'd just have to reinvent to your own liking. (That is to say, even pmdev don't have access to the code of those features.)

    Nonetheless, I have it in mind to create a "new PerlMonks" using Perl 6, doing a lot of things differently based on "lessons learned" from the experiences here, but preserving as much as possible the foundational philosophies of this site. See New PerlMonks for Perl 6 - A Good Idea

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

      It would certainly be a good idea to move all existing (user) content and users to the new framework and keep it on the existing domain. Or at least the postings/threads and users. As for the passwords, there could be an easy solution: Implement in the old Everything engine (which we'll keep around for some time in readonly mode) a function to "activate my account on new perlmonks" as some kind of password change function; except that the user athentificates against the EE, and changes his/her password on both sites (which also locks the account on EE and unlocks it on PM::New).

      As for Perl 5 vs. 6; i'd probably implement it in 5 with existing and tested frameworks (waiting for a stable framework in 6 for years without getting PM into the 21st century doesn't sound that good an option). Since quite a lot sites and projects depend on 5->6 interoperability and smooth upgrade options anyway, we'll be able to port the site step-by-step over time to 6 anyway (i hope).

      Of course, this would all be depending on the good will of the gods. But as long as they don't have to do all the work (and keep their goodly status), i doubt they will be very much against the project ;-)

      Don't use '#ff0000':
      use Acme::AutoColor; my $redcolor = RED();
      All colors subject to change without notice.

        Ah, well then that is completely distinct project from the one I envision, as it disagrees on both main points.