[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Oh, I see.  Without LIKEDS (not available in V4R4, I think) wouldn't the
code get rather cumbersome?  I do like the idea (especially with LikeDS
capability) - just not sure how to make code that supports it manageable at

Dennis Lovelady
"An autobiography usually reveals nothing bad about its writer except his
        -- Franklin P. Jones 

> 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
> > 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
> > http://www.linkedin.com/in/dennislovelady
> -----------------------------------------------------------------------
> 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: