rxapi will be a completely new implementation that will be mostly common code. I'm in the process of reworking this in my sandbox version now, since this will be a rather disruptive change. The current plan is to scrap the shared memory system used by both Windows and *ix and replace it with a daemon process that uses TCP connections to pass messages back and forth. This new replacement is probably at least 95% common code between the implementation, which will make it easier to maintain in the future. It will probably also be more reliable because it won't be dependent on shared memory.
Rick On Sat, Jul 26, 2008 at 8:12 AM, Moritz Hoffmann <[EMAIL PROTECTED]> wrote: > Hi, > I think your ideas are very good. I always had difficulties finding out what > file is in which directory. The proposed parts of interpreter, rexxlib and > rexxapi, plus all the additional libraries makes sense to me. It will allow > new uses to become familiar with the code much faster. On top, if there will > be a real debian package once (or for any other platform) it is much easier > to break it into smaller packages, rexx, librexx, rexxapi, rxsocks, rxutils > etc. I guess I'll try to get oorexx into the debian tree as soon as 4.0 is > released. > > How will the rxapi process be implemented on *nix? That's one part I did not > fully understand, and when looking at the current unix code of rexxapi it > still seems like the original code :-) > > Well, I think 4.0 is going to give us a good platform to base further > development on. > > Moritz > > On Sat, 26 Jul 2008 08:00:20 -0400 > "Rick McGuire" <[EMAIL PROTECTED]> wrote: > >> Now that I'm porting the rxapi/rexxapi code from 4.0 back into trunk, >> I'm starting to think we need to organize the code a bit. Focusing >> for a moment on just the core pieces, we have 3 main executables. >> These are rexx.dll (forgive me for using the Windows terminology), >> rexxapi.dll, and rxapi.exe. I'm going to discuss this in terms of the >> code these are executables are built from, which tends to suggest an >> organization. Because of the rewrite, there's a bit of code sharing >> going on between these components, so our current organization is >> going to be somewhat non-optimal. >> >> For the rexx.dll, this is totally contained in the kernel >> subdirectory, with the exception of some small bits of code in lib and >> the API header files in api. The lib directory could easily go away >> with a reorg...and I'd be happy to see it go. Of the two header files >> still in there, one can easily be eliminated entirely, and the other >> likely belongs elsewhere anyway. >> >> Under the kernel directory is a platform subdirectory, with windows >> and unix branches. In the plaform directories, there's two types of >> code. The first type is code that implements facilities on behalf of >> the internpreter and is fully cognizant of the interpreter code. The >> second category is code that implements interpreter-independent >> abstractions of system factilities. SysFile and SysSemaphore are in >> that category. The new rexxapi.dll and rxapi.exe code will depend on >> this second category, so it should reside somewhere else. >> >> For rexxapi.dll, there's multiple categories of code used: 1) Code >> that implements the APIs and the client-side of the API code, 2) >> Access to some system facilities such as SysFile and SysSemaphore, 3) >> access to system facilities that are specific to the rexxapi.dll >> function (similar to the platform code used in kernel), and 4) >> classes that are used both by rexxapi.dll and rxapi.exe. This code is >> platform independent, but are shared classes that define the data used >> to pass messages back and forth between the client and the server. >> >> rxapi.exe has the same categories as rexxapi.dll. >> >> This seems to suggest the following organization: >> >> kernel (rename to interpreter maybe?) - Contains the interpreter code, >> plus all interfaces to interpreter specific platform facilities. >> Pretty much as it is today, but with classes like SysFile and >> SysSemaphore moved elsewhere. >> >> lib (maybe a different name) - Contains code that can be used by any >> component. This can contain both platform-independent and >> platform-dependent code, using the standard platform organization. >> >> rexxapi - all code used to implement both rexxapi and rxapi. This >> will be organized into client and server subdirs (names open for >> debate), plus a "shared" subdir for code that is used by both. >> >> As an additional cleanup, I'd love to see the rexxutils subdirectory >> reworked so that each extension (rxsock, rxmath, rexxutil) has it's >> own directory organization. >> >> Thoughts? >> >> Rick >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > -- > Moritz Hoffmann <[EMAIL PROTECTED]> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
