Antwort: RE: httpapi.XML parse problem

[thomas.raddatz@xxxxxx]

Thank you, Mike. I am back on the track.

Thomas.

ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 21.01.2009 23:12:41:

> Hi Thomas,
>
> > I think that I got lost and that I did not thoroughly understand your
> > last thought. What I do not
> > understand is why we need different version procedures.
>
> We don't need it for HTTPAPI. For HTTPAPI purposes, we don't need a local
> version or to use "dynamic binding". Scott already provides for that by
> these constants.
>
> PrintLine = HTTPAPI_VERSION + ' ' + HTTPAPI_RELDATE;
>
> However, I was trying to provide for this to be useful to get a version
from
> any set of programs. Yes, it is much more complex. And I think we are
> actually thinking along the same lines. Your example you gave is very
much
> in line with my thinking. And you got around to seeing how the different
> version procedures might be used.
>
> >
> > I also do not understand why the <version_procedure> element overrides
> > the <version> element because
> > both elements specify totally different information.
>
> They specify different information, but "return" the same thing when
looked
> at through version() - a version identifier (1.23).
>
> Version() should return a version number. How it does this is particular
to
> what it is trying to find. If I just say version('*HTTPAPI'), it would
look
> at the local database (text, xml, or pf), lookup HTTPAPI and return with
the
> version number. How does it find version number? If, when looking up
> 'product', it finds a <version> element (or attribute), we have
information,
> but aren't quite done. If we look further and find <version_procedure>,
it
> would do the dynamic binding thing and retrieve version using
> HTTPAPI_getVersion. If the <version_procedure> element does not exist,
> return with <version>.
>
> This allows for retrieving version for 'product' that doesn't have a
service
> program. For example, you have CHGOBJDA tool that doesn't appear to have
a
> service program of its own. You could still use version('*CHGOBJDA') on a
> local system to find the version. It would look up the product in the
local
> database and return the <version> value.
>
> For remote versions, I only imagine one version of "the truth", although
at
> some point we might be able to accommodate multiple versions (betas,
"old"
> versions, etc). So to retrieve a remote tool description, we obviously
would
> ignore the <version_procedure> element and just retrieve <version> and we
> would call the procedure in the "same way"...
>
> Version('http://www.tools400.de/Downloads/Freeware/Tools/chgobjda.xml')
>
> I think the example that you provided is pretty accurate, but I'd like to
> see version() be generic (can be hardcoded internally for now).
>
> Maybe we need to prefix these procedures to make them a little less
generic
> (along the lines that Scott uses for HTTPAPI). Anyone got some names for
> this thing?
>
> Mike Krebs
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> 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.
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------