Re: EXPORT, IMPORT and FTPAPI

[thomas.raddatz@xxxxxx]

   Charles,
   I completely agree with you. Beside encapsulating the session
   implementation in a separate module I also would merge all the MODS
   into a single wkSession structure. I am not completely sure about it
   but I think that I introduced most of the MODS when I enhanced FTPAPI
   to run multiple sessions without conflicts. I did it that way because
   I had not enough time to do it right.
   So something like that might be the right way to go:
     // Initializes the sessions module. Called only once.
     SESSIONS_initialize()
     // Creates a new instance.
     SESSIONS_newInstance()
     // Returns the instance that is
     // associated to a given handle
     SESSIONS_getInstance()
     // Saves a given instance
     SESSIONS_saveInstance()
     // Destroys a given instance
     SESSIONS_destroyInstance()
     // Terminates the session module. Called only once.
     // May check for active instances and either throw
     // an error messages or gently terminate the instances.
     SESSIONS_terminate()
   Thomas.
   ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 18.10.2010 15:12:14:
   > Von: charles.wilt@xxxxxxxxx
   > An: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
   > Datum: 18.10.2010 15:16
   > Betreff: Re: EXPORT, IMPORT and FTPAPI
   > Gesendet von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   >
   > Dennis,
   >
   > I'm not talking about simply moving existing procedures...I'm
   talking
   > about a new SESSION module to encapsulate the MODS session
   > implementation.
   >
   > I went back and looked at FTPAPI, since it had been awhile...
   >
   > It might be a significant rewrite to decouple the FTP procedures
   from
   > the MODS session implementation...though I have to think it would be
   > worthwhile...
   >
   > A shortcut might be to have a SESSION_GetInstance() at the beginning
   > of the procedures  to retrieve  the single instance a procedure
   needs
   > to work with.  Processes that update session variables could then
   call
   > a SESSION_SaveInstance() at the end to store the changes.
   >
   > If I get a chance, I'll take a longer and harder look at what just
   > what would be involved.
   >
   > Charles
   >
   >
   >
   > On Mon, Oct 18, 2010 at 8:31 AM, Dennis Lovelady
   <iseries@xxxxxxxxxxxx> wrote:
   > > Thanks, Charles.
   > >
   > > That would seem cleaner - but the fact is, that's what we have
   now, and as
   > > Scott indicted in the comments, the module is larger than we might
   lock.
   > > Maybe I'm missing something but I cannot envision a way to put all
   the
   > > references to MODS subfields into one module without limiting
   ourselves to
   > > only that one module, since the multi-occurrence variables are
   used all over
   > > the place.  (Consider, for example, wkErrNum, which is a subfield
   of MODS
   > > wkSession...)  So I'm interested - how would you pull this off?
   (It's a
   > > serious question; maybe I'm missing something important.)
   > >
   > > The only cleaner-looking way _I_ can come up with for this, is to
   use
   > > pointers exclusively, especially if we're going to keep V4
   compatibility.
   > > But that would move the initialization of the variables away from
   their
   > > definitions.  Maybe that's not such a big deal, but I think
   there's value in
   > > having the definition tied to the initial values.  And I really
   like that
   > > one RESET can set a slew of variables to their initialization
   values.
   > > Apparently someone else liked that, too.
   > >
   > > Dennis Lovelady
   > > [1]http://www.linkedin.com/in/dennislovelady
   >
   ----------------------------------------------------------------------
   -
   > This is the FTPAPI mailing list.  To unsubscribe, please go to:
   > [2]http://www.scottklement.com/mailman/listinfo/ftpapi
   >
   ----------------------------------------------------------------------
   -
   >

   --
   IMPORTANT NOTICE:
   This email is confidential, may be legally privileged, and is for the
   intended recipient only. Access, disclosure, copying, distribution, or
   reliance on any of it by anyone else is prohibited and may be a
   criminal
   offence. Please delete if obtained in error and email confirmation to
   the sender.

References

   1. http://www.linkedin.com/in/dennislovelady
   2. http://www.scottklement.com/mailman/listinfo/ftpapi

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------