Etomite Api changes not changed in Mod-X?

I think, then, we are both in agreement. Obviously, it’s working now, I wouldn’t argue to go ripping them out. To clarify my previous comment: I don’t think we should be spending continued efforts to keep ourselves compatible and once the time arises that Etomite releases a version that we aren’t still compatible with, I think we should seriously look at just dropping support altogether. (Hence my 1.0 reference, since I’m fairly certain that if they pick up development, we will be incompatible by then.)

Just going through our API, there’s a lot of cruft in there already just for the sake of being compatible. Just don’t want to see this expand any further than it already has.

Edit: On thinking this through even further, I have an idea that I think is brilliant: why not move all all of these deprecated functions and Etomite hacks into a new class, let’s call it Etomite, that extends the current class. Then we add a new switch in the admin screen that says something like "Do you want to enable backwards compatibility with Etomite 0.6?" If that switch is set to yes, we include both our API and the Etomite override.

The result: the core API can be considerably cleaned up and streamlined and exactly match our official, documented API, resulting in a much leaner codebase for all of us (like myself) that need the best possible performance and has no need to support legacy Etomite code. However, for those with older sites and/or that want the cross compatability, both classes are included and $modx and $etomite would both be usable.

The nice thing about this is that if certain function changes need to be made on either side, they can be accomodated, since the Etomite extender class can either override our native API calls, implement conflicting functions from Etomite, etc. In addition if someone wanted to continue supporting Etomite, they could do so by just continuing to work in the legacy class without affecting the performance in the main parser.

Thoughts? Is this stupid? To me it makes perfect sense, but I’m on a sugar high from my wildberry mocha.


:)

LOL... as far as I’m concerned, keep drinkin’ them mochas!

Love the idea and think it makes total sense. +1 from me!

I don’t think this should be be the goal of TP4. We stiill bee such features for existing system at top speed. Future version TP5 or 1.o can then move to such

Well, except that as part of the new manager I’m having to rewrite large parts of the backend, so it would be very trivial for me to do it now if everyone is interested. Not to mention I’m already ripping it out for my own project that absolutely has to be streamlined, so it would just be a matter of sticking them into a class file instead of deleting them (getting ready to run MODx on a site that will get over a million hits a day, and the current parser isn’t up to the task).

If you’re doing it now, then might as well do it now!

+1 from me, though I think we should have a way to easily add/remove any number of user-definable API sets, similar to what is being discussed here with maintaining Etomite compatibility; or maybe this should just be a module with a plugin to add the extended API pieces?. Either way, it would be a great way to allow any number of extensions (or overrides) to the core parser while avoiding a lot of upgrade conflicts. I for one want to encourage the development of custom mods for MODx, while avoiding the conflicts that can easily arise from such situations, and an Etomite compatibility module whould be a great example of either approach.

Quote from: rthrash at Aug 21, 2005, 04:57 PM

If you’re doing it now, then might as well do it now!

After thinking this through I think this would certainly impact existing MODx sites that makes use of Etomite snippets or even pure modx snippets. By moving Eto specific function (which I think are few in numbers) into a separate class file will add another file include overhead.

I’m not in agreement with this.

Existing functions that are seen as deprecated should be labeled as such and where possible be made into a wrapper around the newer modx functions.

On the question of MODx not being able to handle 1 million hits per day. That I’m not so sure of. Every system (even the best of them) has design issues. The current parser is able to render pages in .07 secs(using a low end system, should be lower on faster machines) which most forums software are not able to do but yet they are handling thousand of users and lots of page views per day. Take SMF for example they current include over 5 external files and renders a page in around .19 secs (as I’ve seen once on their server).

Well that’s my 2 cents

While I considered modules, I had two issues that I couldn’t readily figure out. If someone can point me to a way to resolve them, I’ll be happy to try to do the module route:

1. How would we initialize a new global class from within the module that overrides the class already in use? (Or, worded another way: is there an interface to pull modules and use them before the parser is started?) Otherwise, I think we’d need to destroy the current $modx parser and reinitialize it with the override class. Maybe I’m just thinking too much here and it’s simpler than that?

2. What happens if you were to try to run more than one API set? Personally, I think this gets into a very hairy area and we should restrict the user to just running one alternate API on top of the core API. Having the switch built into the admin makes this easy (it’s just a drop down with MODX 1.0, Etomite 0.6, <insert other here>), but I don’t know how you could stop someone from turning on three or four APIs using a module system. ??

Am I completely off track here?

Quote from: xwisdom at Aug 21, 2005, 05:09 PM

On the question of MODx not being able to handle 1 million hits per day. That I’m not so sure of. Every system (even the best of them) has design issues. The current parser is able to render pages in .07 secs(using a low end system, should be lower on faster machines) which most forums software are not able to do but yet they are handling thousand of users and lots of page views per day.

I’ve already done some preliminary tests on this and the performance was (well) under the current system running the site (by a factor of almost 3). A large part of that is the memory usage.

On a busy system, the overcommitment of memory is going to be a much larger factor than whether or not you include another file.

Not to mention we already have things like manager/includes/extenders/* which are included in the document.parser, which to me shows that we aren’t as concerned with creating additional files as we are with trying to make sure the core is as clean as it can be.

In one quick test, I stripped 10k out of the parser by removing all the redudant and deprecated functions and was still able to run the test template, the front end editing, the backend, and everything else without any errors. To me that’s a pretty substantial savings, especially if you multiply it over the type of traffic I am talking about. And that’s before correcting things like this:

which just made TWO copies of the parser (meaning my savings just stripped 20k out of the memory usage).

Quote from: infoclipper at Aug 21, 2005, 05:12 PM

While I considered modules, I had two issues that I couldn’t readily figure out. If someone can point me to a way to resolve them, I’ll be happy to try to do the module route:

1. How would we initialize a new global class from within the module that overrides the class already in use? (Or, worded another way: is there an interface to pull modules and use them before the parser is started?) Otherwise, I think we’d need to destroy the current $modx parser and reinitialize it with the override class. Maybe I’m just thinking too much here and it’s simpler than that?

Wouldn’t this be the job of a plugin; dynamically adding the $etomite object, making it available for the parser? I am not suggesting replacing the $modx object what so ever. Just interested in creating new objects with additional API’s to make available to the site resources. To override existing behavior is another subject, and one I’m not familiar enough with the parser to discuss intelligently at this point, though I imagine it would have to be done using the extenders approach. I was suggesting the ability to allow user-defined extenders to allow extensions to the parser, unless it could be solved using a module/plugin.

Quote from: infoclipper at Aug 21, 2005, 05:12 PM

2. What happens if you were to try to run more than one API set? Personally, I think this gets into a very hairy area and we should restrict the user to just running one alternate API on top of the core API. Having the switch built into the admin makes this easy (it’s just a drop down with MODX 1.0, Etomite 0.6, <insert other here>), but I don’t know how you could stop someone from turning on three or four APIs using a module system. ??

Am I completely off track here?

Well, I never meant to replace the core MODx API, just in adding extension API’s to it. Overriding specific API functions would be best left to pluggable core implementation classes from the backend (where maybe you specify the core parser class implementation to execute in the system settings).