[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EXPORT, IMPORT and FTPAPI
Thomas,
Yeah, that's the direction I was leaning towards...
I'd really like it if we could rework it so we don't have to pass the
session DS back and forth...
But that would be a lot more work; since the SESSION stuff would all
be internal anyway, just passing the DS is probably the most cost
effective choice.
Charles
On Mon, Oct 18, 2010 at 11:27 AM, <thomas.raddatz@xxxxxx> wrote:
>
> 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
> -----------------------------------------------------------------------
>
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------