Re: Total speculation?

Would it be possible, a huge amount of work etc. to set up a band-width/cpu constrained, version of PM running on (one of) the existing server(s) that could have patches applied by lesser mortals than the gods, so that they might be exercised in a non-critical environment?

We have one of those already, but it too is gods only, because both the code and all data lives in the same database. I don't know how much of a problem it would be to separate the code so that exact functional duplicates of PM could be set up, but it too needs someone to do this work at the very least. (I might look into it later tonight or maybe tomorrow.)

Another discouraging problem (for newcomers anyway) is that it's not readily obvious if a node is in use or contains dead code, and we have a lot of the latter..

I'd also bet that besides a few gods, noone really understands more than a small portion of the interactions implications of the complete engine. tye in particular has spent a lot of time optimizing PM's engine flavour and pulling at its innards. I doubt there are a lot of people who can do remotely as much as him or a handful of other gods, which is why I tried to make a move for a tye fund.

Besides that, the most practical and most promising but also least feasible thing I can think of that we could now to alleviate as many of the problems as possible would be to try and migrate PM to a current version of Everything, so EveryDevel and PM can benefit from increased synergy. However, it's nearly as large a project as a full rewrite of a new engine..

Personally, (as I've said a bunch of times in the last couple of days) I'd really prefer if no code were stored in the database since that would allow working with standard tools (of which CVS or cousins would be very desirable), but it's not likely that PM is ever going to (be) switch(ed) to such. So being able to share work with EveryDevel seems like the most practical way to generate the synergies we'd need to bump along faster.

Makeshifts last the longest.

Comment on Re: Total speculation?

Replies are listed 'Best First'.
Re: Re: Total speculation? by BrowserUk (Patriarch) on Oct 03, 2003 at 07:41 UTC
The notion that keeps buzzing around in my head is COW! Copy on Write. Have the test server access the live database (readonly), but tweak the reads so that a look aside table is accessed first. If the request can be satisfied from there, it is, and any modified nodes would be trialled into the lookaside table. If the requested node is not in the LAT, then it is taken from the live table. If the request results in an update(s), these are made to the LAT not the live DB. Hmm. How easy is that to set up? Probably not at all, but the thought kept buzzing, so I mentioned it. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller If I understand your problem, I can solve it! Of course, the same can be said for you.	[reply]
Re^3: Total speculation? by Aristotle (Chancellor) on Oct 03, 2003 at 15:39 UTC
That's an interesting idea, but - where is authorization for node accesses done? If it happens on the development server (and I don't see how you could feasibly do it elsewhere, ie on the live site), anyone who can apply patches can patch the authorization code and so grant himself full access.. Makeshifts last the longest.	[reply]
Re: Re^3: Total speculation? by BrowserUk (Patriarch) on Oct 03, 2003 at 16:26 UTC
I'm not sure of what mechanisms are currently in place for updating nodes, but that same mechanism would still be used. (ie. on the live site). The difference would be that non-god authorised users updates would be made into the look-aside table rather than the real database. There would also be a list of prohibited nodes. Attempts by non-god authorised users to read prohibited nodes fails. Updates to a node can only be made if the user has previously read the node. All of the authorisation and node update nodes are on the prohibited list and can only be run from the live system. The LAT is only used from the test system, so no updates can be made there. That's not very well described, is probably flawed, but it's almost certainly a waste of effort to even think about it further. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller If I understand your problem, I can solve it! Of course, the same can be said for you.	[reply]


Keep It Simple, Stupid
	PerlMonks