[DUG] Validating CDS files
Alister Christie
alister at salespartner.co.nz
Tue Jan 18 14:35:51 NZDT 2011
Well put ;-)
Alister Christie
Computers for People
Ph: 04 471 1849 Fax: 04 471 1266
http://www.salespartner.co.nz
PO Box 13085
Johnsonville
Wellington
On 18/01/2011 1:40 p.m., Kyley Harris wrote:
> I'm wondering if you analyzed your need for popcorn carefullly. You
> asked for popcorn.. you got your popcorn. but perhaps you've been
> taken for a ride. If we analyze your need carefully for an hour, what
> we could have determined is that you truley wanted a 30 minute comedy
> show, and some salt - and -vinegar chips to go with it. Not popcorn at
> all. Perhaps the desire for popcorn stemmed from your not correctly
> seeing your needs in the first place. I feel its my duty to help you
> access the situtation so that you get what you need and not what you want.
>
> We could discuss this further privately, and I'm sure with all my
> experience in these situations that a 3 hour lunch break daily, with
> said included comedies and chips will satisfy your needs more
> appropriately.. The Popcorn is just a bandaid.
>
> On Tue, Jan 18, 2011 at 12:44 PM, David Brennan
> <dugdavid at dbsolutions.co.nz <mailto:dugdavid at dbsolutions.co.nz>> wrote:
>
> Mmmm, I'm enjoying my popcorn as I watch...
>
> -----Original Message-----
> From: delphi-bounces at delphi.org.nz
> <mailto:delphi-bounces at delphi.org.nz>
> [mailto:delphi-bounces at delphi.org.nz
> <mailto:delphi-bounces at delphi.org.nz>] On
> Behalf Of Matthew Comb
> Sent: Tuesday, 18 January 2011 11:12 a.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: Re: [DUG] Validating CDS files
>
> > Those developers that came back with "TO DO" lists were perhaps
> themselves
> > not taking the time to understand the customers problems. The
> customer
> > told
> > them "those 10,000 features are great, but we'd really like X, Y
> and Z",
> > so
> > the developers simply came back to you with that list of "X, Y
> and Z".
> >
> > Far from analysing too much, they were most likely not analysing
> *enough*.
>
> What your argument does not take into account yet again (which was my
> point that was missed), is the time and money factor. If you have
> a 1 day
> or 2 day install, you do not have time to spend all 2 days taking on
> customer requests when the customer is not yet up to speed with the
> capabilities of the system. A customer often doesn't know what
> they need
> until they get to use the system, then their requirements frequently
> change. If you have unlimited time and money then by all means, spend
> every waking moment analysing each and every item raised, Cameron
> would
> probably tear his hair out.
>
> >
> >
> > That specialist you hired is most likely looking at the X, Y and
> Z and
> > then
> > asking the customer... "But what do you need X, Y and Z for?"
> then showing
> > them that they already HAVE X, Y and Z among the 10,000 other
> features.
> >
> >
> > That quite neatly demonstrates my point I think. Understand the
> > problem...
> > not only might the solution you are asking for not be ideal, but
> you might
> > already be in possession of the solution !!!
> >
>
> I don't think it does at all.
>
> >
> >
> > "I have a legacy piece of software which very very rarely
> corrupts a
> > local data file - fact"
> >
> > The real problem to be solved is how/why the corruption occurs...
> > everything
> > else is just sticking plaster, not a solution, and even the sticking
> > plaster
> > can only help if you apply the right sort of dressing correctly.
>
> Thats right, that is the root problem, but as this piece of
> software has
> been in the field for 8 years, and is being decommissioned, there
> isn't a
> lot of point in that is there. So a bandaid is more than adequate.
>
> >
> >
> > "Regardless of the better long term solutions, we will take
> > a defensive programming measure to protect against the loading
> > of corrupt files."
> >
> > And my point in this area was that unless you understand
> how/where the
> > corruption is occurring, the defensive measures you might take
> may very
> > well
> > end up not being defensive at all.
>
> If you validate a CDS file, and don't load it if it is corrupt.
> That is a
> defensive measure.
>
> >
> > e.g. the idea of checksuming the output from the server... if
> the data
> > coming from the server is corrupt from the get-go, then
> check-summing
> > helps
> > you not one little bit.
> >
>
> Agreed which is why I didn't ask about it.
>
> >
> >
> > You initially blamed the corruption on a flaky wifi connection -
> highly
> > unlikely for the reasons that I and others have explained. You then
> > explained that you were streaming the data, so the corruption
> might occur
> > in
> > sporadic bytes in the stream.
>
> I do not believe I did suggest the contents of the stream would be
> changed. What I said was that a TCP steam can be disconnected.
> this was
> yet another wild assumption on your part. If you send a 1GB file
> through a
> stream, it is NOT as Kyley suggested an All or Nothing approach.
> You are
> taking bytes into a stream. It is up to you whether or not you
> discard the
> stream based on a disconnection or not. That decision point is out
> of my
> control as it is Midas + DBX4MySQL which manages this.
>
> >
> > But then you seemed attracted to the idea of using XML as a
> potential way
> > forward, which would seem to contradict the streaming nature of
> the data
> > transmission.
>
> The incorrect assumption you made at the beginnning was that the
> CDS file
> was coming from the server as a file payload. Its not. The client is
> connecting to MySQL DB server directly. All suggestions and
> misunderstandings about hashing, file downloads, etc were based on
> that
> incorrect assumption.
>
> >
> > And now you admit:
> >
> > "I do not know yet where this corruption occurs. DB Server,
> Drivers,
> > In Memory, Saving of the file, Server DB."
>
> I don't, and it doesn't matter. Why ? Because at a rate of 1/10000
> it is a
> manageable issue, and with the software being decommissioned it is
> good
> business sense to investigate the server mechanics. its better to
> bandaid
> and move on.
>
> >
> >
> >
> >
> >
> > "Its not true to take the standpoint that if someone asks for the
> > solution
> > then they should be able to provide it e.g If I ask for Word
> 2010
> > should
> > I be capable of sitting down and writing the application suite?"
> >
> > I didn't say that they *should* be able to provide it in the
> sense that
> > you
> > took it to mean - I said as to draw attention to the inherent
> > contradiction.
> > The only way you can confidently ask for a solution in the form of a
> > solution specification, without explaining the problem, is if
> you fully
> > understand the problem and *could* provide the solution
> yourself. In
> > which
> > case, you would never have needed to ask someone else to provide the
> > solution for you.
>
> Thats just rubbish.
>
> >
> > In other words, when someone asks for a solution, rather than
> stating a
> > problem, the likelihood is that they are asking for the wrong
> solution
> > from
> > the very start!
>
> Statistically probably correct more often than not, but still an
> arrogant
> assumption that the person is clueless / uninformed of possible
> solutions.
>
> Its also arrogant to assume you know everything abou the
> motivation and
> drivers as to why the person asked the question in the first place.
>
> For example in this case, the fact that the software is being
> decommissioned and the fact that its rarity does not make a server
> solution fiscally viable.
>
> >
> >
> > Your "Word 2010" example this is a quite different sort of
> request from
> > what
> > we are actually discussing (it's not a "technical solution" just a
> > shopping
> > list), never-the-less even this inappropriate parallel can be
> used to
> > illustrate the same point:
> >
> >
> > If you ask for Word 2010, should I just sell it to you simply
> because you
> > can't write it yourself ?
>
> That logic much like the rest of your logic is flawed. I did not
> say that
> you should sell it to me because I could not program it. You
> should sell
> it to me because I asked to buy it.
>
> I am asking to buy it, because I don't want to program it.
>
> >
> > Or should I first ask what you need it for.... ?
> >
> > If you tell me you want it for doing bulk emails, and you heard
> that Word
> > 2010 has some neat mail-merging capabilities, then I am pretty
> confident
> > that I can sell you a better solution for your needs than just
> handing
> > over
> > a copy of Word 2010.
>
> Again you are incorrectly assuming that the person asking the
> question is
> a retard.
>
> >
> > I could just give you what you want, but that may not be what
> you need.
> >
>
> Its not your decision to make.
>
> >
> > Incidentally, nobody "gave me" a blog. I created my blog in
> order to
> > share
> > my skills and experience and - if my stats are to be believed -
> many, many
> > people appreciate it.
>
> Actually I've found your blog to be very good and useful. I feel
> that if
> you reigned in the arrogance a tad, you might get places faster.
>
> > I gain some sense of satisfaction from the fact that people
> (well, *some*
> > people at least) seem to appreciate my effort, but it certainly
> doesn't
> > "go
> > to my head".
> >
> > _______________________________________________
> > NZ Borland Developers Group - Delphi mailing list
> > Post: delphi at delphi.org.nz <mailto:delphi at delphi.org.nz>
> > Admin: http://delphi.org.nz/mailman/listinfo/delphi
> > Unsubscribe: send an email to delphi-request at delphi.org.nz
> <mailto:delphi-request at delphi.org.nz> with Subject:
> > unsubscribe
> >
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz <mailto:delphi at delphi.org.nz>
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz
> <mailto:delphi-request at delphi.org.nz> with Subject:
> unsubscribe
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz <mailto:delphi at delphi.org.nz>
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz
> <mailto:delphi-request at delphi.org.nz> with Subject: unsubscribe
>
>
>
>
> --
> Kyley Harris
> Harris Software
> +64-21-671-821
>
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject: unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20110118/ebccc201/attachment-0001.html
More information about the Delphi
mailing list