Re: EXPORT, IMPORT and FTPAPI

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Dennis,

LIKEDS would certainly be a key...

I wouldn't lose any sleep over not supporting v4r4....I don't believe
Scott would either.  He could always leave the existing version
available for those on a release prior to v5r2 (or v5r4) like he does
the v3r2 compatible version of FTPAPI.

Heck, I wouldn't mind seeing it in free-format for that matter.

Charles

On Mon, Oct 18, 2010 at 11:35 AM, Dennis Lovelady <iseries@xxxxxxxxxxxx> wrote:
> 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
> V4.
>
> Dennis Lovelady
> http://www.linkedin.com/in/dennislovelady
> --
> "An autobiography usually reveals nothing bad about its writer except his
> memory."
>        -- 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
>> 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
>> > 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:
> 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
-----------------------------------------------------------------------