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

20040723: EUMETSAT MSG ADDE server



>From: Unidata Support <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200407020423.i624NgaW002282 McIDAS-X build

Patrick,

First, I want to apologize for having to skip out yesterday before
getting Marianne's MSG server to work.  I just made it back in time for
the interview, so all was well from my side.  Since I had been
preoccupied with two interviews and the vain attempts to get the MSG
server working, the amount of email I had to deal with prevented me
from taking further looks at the code yesterday evening.

So, the question back to you is whether or not you would like me to
take another look at Marianne's code and fix it so it will work?  Afer
reflecting on what I saw, I would recommend doing some serious
rewriting of her stuff to make it more general and use McIDAS library
routines in stead of the ones I had to dig to find in the UCB library,
/usr/ucblib/libucb.a.  I don't want to dive in and start making changes
if you are planning on doing the same yourself.  Please let me know how
you think we should proceed.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.

>From address@hidden  Fri Jul 23 12:21:49 2004

Hi Tom,

On Fri, 23 Jul 2004, Unidata Support wrote:

> Patrick,
>
> First, I want to apologize for having to skip out yesterday before
> getting Marianne's MSG server to work.  I just made it back in time for
> the interview, so all was well from my side.  Since I had been
> preoccupied with two interviews and the vain attempts to get the MSG
> server working, the amount of email I had to deal with prevented me
> from taking further looks at the code yesterday evening.

Tom, no apology needed.  We're the one's that owe you big time here.
We're very fortunate to have had your help and in fact both Jochen and I
really felt sorry you ended up spending the better part of your day
trying to tackle the programming issues.  This turned out to be far more
complex than anything we anticipated, and the approach doesn't seem to
reflect very well the MSG servers built by Wisconsin.

> So, the question back to you is whether or not you would like me to
> take another look at Marianne's code and fix it so it will work?  Afer
> reflecting on what I saw, I would recommend doing some serious
> rewriting of her stuff to make it more general and use McIDAS library
> routines in stead of the ones I had to dig to find in the UCB library,
> /usr/ucblib/libucb.a.  I don't want to dive in and start making changes
> if you are planning on doing the same yourself.  Please let me know how
> you think we should proceed.

I tend to agree with you here.  Given the state of the code, and if we
really want to adapt this and make it more flexible and robust,
even make it available for others to use, additional work is needed to
bring in line with McIDAS conventions.  (I'm still not clear why the
Wisconsin msg servers won't work here...the minor navigation
corrections aside and Jochen does not seem to know much about the
Wisconsin effort either).

Realistically, given the time and priorities I have at the moment (not
that I wouldn't like the challenge), not to mention the spinup I would
need to even come close to your level of understanding of the server code,
I personally can't see myself tackling this at the moment.  Sure, it would
eventually be nice to view the Gb's of case data Jochen brought with him,
but I feel I don't have enough information at the moment to justify the
effort when I'm not even clear why there are apparently two different
set of servers, one with what Wisconsin has come up with and the other
what Marianne has cooked up here.  I'm not sure we want to be duplicating
efforts or investing a significant amount of time if these MSGS/MSGH
servers are only applicable to the data Jochen brought and intended
primarily for in-house use.  Sounds like this really goes back to the
issue you brought up yesterday when we talked about the need for an ADDE
server on EUMETSAT's end to deal precisely with this kind of format
handling issue that should be handled on the server end and transparent to
the user.

Let me know Tom if you have additional thoughts on this.  I'm just a
bit hesitant on proceeding at the moment without a) having a better
idea how much more effort we would need to invest and b) whether that
effort would really pay off in terms of any wider application down the
road.

Have a great soggy Friday,

Patrick


pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy