On Thursday, March 03, 2016 07:52:42 AM Thomas Eckardt wrote: > >so most > >anything people are running is either Unix based or Windows. > > AGAIN: assp is build to run on ALL OS - there are more than unix, linux, > wndows and OSX
I doubt ASSP is running on many OS if any that are not Unix based or Windows. Any mainstream OS is either Unix based, or its Windows. There is nothing else in mass use. > >It works just the same. > > No, if the assp installation rules are brocken, several features will not > work. I can always test out and confirm such assumptions. > ONLY one for example - configuartion synchronization: How can a linux and > a windows assp-system working in an assp-cluster sharing the > configuration, if the linux-assp uses absolute path definitions? > But there much more feature that will not work in this case. Again the path does not matter, long as ASSP knows where the config files are, it would share and sync them just the same. Relative or absolute paths are moot. > assp.pl has two parts > > 1. the main part (ending at line 6850 in V2 build 16060) > 2. the engine part (the rest until the end) > > Depending on the used environment, Perl version, Perl modules, assp/lib > modules, plugins and the calling convensions (run or syntax check) - the > main part of the code modifies it self. The main part also modifies the > engine part using the same dependencies. The main part also modifies the > perl namespace of several perl modules. If the 'lib/AsspSelfLoader.pm' is > installed, the main part is splitting the engine part in its smalles > possible parts (assp/sl-cache). The engine part cleans up it self from > unneeded main part and engine part code after startup. That is the one module I am not using. I will look to start using it and see if any difference. > If anyone changes the assp.pl V2 code using 'sed' to replace $base and > other parts - or the assp install convensions are broken - the resulting > runtime code is not predictable! Still seems to work just the same, no errors, no missing function. No unwanted emails/spam making it through, other than the occasional anomaly. > This technology requires that assp.pl is one file in the > assp-distribution. It is simply not possible to modify ~30 single > assp-engine-modules (and there parts) this way. There are many perl programs done this way, Bugzilla is an example, and there are others. > If assp would be splitted in to different modules - this will require: > - an engine module version check and management Only if the modules care about the version of the others. Which really should only matter if the API changes. Otherwise version should mostly be moot. > - a complete different distribution management > - a complete different autoupdate mechanism CPAN? > - a configuration <-> file content <-> engine module crosscheck management Not sure what you mean here > - code redesign for ALL internal subroutine calls, because of the changed > calling convension for modules Likely no way around that. > - code redesign of all plugins and all assp lib modules That might be a good thing given the age of the code base. I do not believe its ever had a complete redesign and code clean up. I believe it has just had features added on over the years, as the file grew. > This will lead in to a complete code redesign. 1000s of hours for nothing. NO, time well spent to make the code base more manageable. It will be in smaller pieces that will allow others to more easily digest and contribute. Not to mention making it like just about every other modern program and project, code split across multiple files. > Thousands lines of code to manage the modules and crosschecks. Slower assp > because the namespace will grow. Much slower start of assp because of the > versions crosschecks. Slowness is all in assumptions. Its possible there could be gains as well optimizing modules as other can see smaller chunks of the code and may have improvements. Seems ASSP already does some version cross checks, and already has some stuff in modules, ASSP_FC, ASSP_SVG, ASSP_WordStem, AsspSelfLoader, and of course the rebuildspamdb.pm. > I'll go off this thread, there is nothing more to say - the discussion is > useless and steals my time. Its question if you want to be the ONLY one working on ASSP, or if you want a more active development team furthering ASSP. Over the years seems like very few are interested in working with ASSP codebase. I have tried to get several I know who are VERY enthusiastic about perl and it is their go to language. However all come back with the same complaint, and NONE are willing to get involved as a result. You talk about your time. But for anyone to further your work, Fritz, John Hanna's and others. They will have to spend tremendous time going through the massive assp.pl single file to get familiar with the code. Due to choices others made to preserver their time so to speak. Very likely in that process they will be put off and not continue or contribute. Which is why many have not come over the years, and I do not believe many are contributing to ASSP development these days. We will not always be around, will our work live beyond us? Do we care about such? Who knows how long ASSP will be around, but it very well could be a project that carries one beyond several of our lifetimes. Having code others can contribute, maintain, and further, will allow past contributors legacy to continue. Otherwise it all just dies, when something else better comes out, or project dies and/or gets forked. Me personally, I would hope my work would continue on, making any time I spent worth while in my lifetime and others... Though in tech that is not to likely, but the potential does exist. Dennis Ritchies work and legacy will live long beyond him.... -- William L. Thomson Jr. Obsidian-Studios, Inc. http://www.obsidian-studios.com ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Assp-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-user
