No Subject

[mediamob <mediamob@dnaco.net>]

******    message to minivend-users from mediamob <mediamob@dnaco.net>     ******

> Date: Wed, 19 Jan 2000 10:15:48 +1100
> From: "Roger B. Arnold" <rbarnold@a-dream.com.au>
> Subject: Re: [mv] RePost Please Help: Newbie questions relating to SQLplease
> help
> 
> ******    message to minivend-users from "Roger B. Arnold"
> <rbarnold@a-dream.com.au>     ******
> 
> Roger wrote:
> 
> Hello Ken,
> 
> Thanks for the reply
> Yes, I have read the manual, and tried to understand what I have read, however
> I
> found the documentation to be un-clear, especially in regard to the catalog.cfg
> file
> set-up in the area of the database, which after all is what MiniVend is all
> about.
> I have also read quite a few FAQ's and performed searches to find the area's
> that
> dealt with this particular part of the .cfg file.
> 
> As far as switching things off to see if it will work or not, fine if (a) you
> have
> got a working MiniVend system and fully understand it, and (b) you have got
> plenty
> of spare time to do a suck-it and see scenario. Unfortunately I don't have the
> time
> (I wish I had), btw has anyone thought about posting a fairly detailed
> explanation
> of how things work in the area of the catalog.cfg file and perhaps the area of
> connecting to a SQL database, instead of getting hot under the collar about
> answering newbie questions? The number of posts about connecting to mysql over
> the
> past week obviously shows that the docs are lacking in this area (for newbies),
> this
> may be annoying to experienced people like yourself but even you were a newbie
> once
> and OK you might have played around with minivend to get your own answers, but
> a lot
> of people don't even know where to start and yet might be quite capable in
> other
> area's.

Roger, I'm right with you - your experience matches my own. I have been
working for more than a year on my first minivend site, and most of my
knowledge is hard won. When I get the site running, my next project will
be a "how I did it" document intended to help intelligent new users pick a
starting place. While that document is not ready, here are some hints I'll
fling out about the minivend universe - feel free to write to me directly
for amplification or more opinions.

Hint #1: There are no _instructions_ for Minivend. Don't waste time
looking; the documentation is documentation in the literal sense. It is
about minivend, it clarifies principles of minivend, it is necessary and
helpful - but it will not tell you how to achieve a goal.

Hint #2: Use the demo catalog for what it is worth, but know what it
is! The demo catalog uses almost all of the available features of
minivend, and it can be hard to tell from the code what feature is used
where. Indeed, some features used in the demo are undocumented, like the
[L][/L] tag pair meaning "locale". 

Hint #3: There is a Minivend "mindset". In general, the questions of those
who do not have this mindset (like me) make little sense to those who
do. An example from my early days: One of my first posts to the mailing
lists asked, "What do I use to maintain MiniVend databases?" The answers
were mostly variations on the theme of :"Whatever you want to use." 

I found this spectacularly unhelpful, because my background up to this
point did not include interoperable systems - For every "database file" I
had ever seen, a proprietary manager which you had dam' well better use
was part of the package. Those who were answering, with some
consternation, " Whatever you want" understood "database" to mean
"collection of data", so the (to them) obvious and helpful possibilites
included: If you are using a database served by an SQL server, write a
{perl or python or php or C or awk} custom frontend , or use a two-way DBI
- SQL translator and edit the DBI with a script in {perl or python, etc,}
or edit an ASCII delimited file (you can choose your delimeter, but be
careful! Every choice has a consequence) with a text editor and let
Minivend convert to DBM format, or not, and so on.

The point here is that to those of us without the minivend mindset, what
looks like grumpy rejection is often simply lack of a frame of reference.

Hint #4: The biggest key to the minivend mindset: There's more than one
way to do it. Abbreviated TMTOWTDI (pronounced Tim-Toady). Minivend shares
this with perl, so those who like perl tend to like minivend too. In both
cases, it means (if you'll forgive oversimplifcation) that almost all
functions, terms, and problems have multiple meanings depending on
context. While there are distinct advantages to this approach, my personal
judgement is that those for whom it is 'natural' tend to be thrilled by
producing as many possibilities as they can, but shy away from discussing
relative merits or dependancies of any given approach directly.

HInt #5: Your work is not wasted. The open and interoperable nature of
Minivend means that formats and structures are relatively easy to
convert. Don't fear a Microsoft-like scenario of building an Access
database only to discover that access does not offer a feature you need
and now you can't transfer the data; if you move on, there will be a way
to recover. This should offer the freedom to begin your catalog without
necessarily knowing what your own optimal choices will be.

Hint #6: It helps to think of minvend in parts. The minivend server
recives directives from catalog configurations, MML (Minivend Markup
Language) tags on Minvend HTML pages, and optionally perl scripts and
subroutines. Based on interaction with these directives and stored data,
the minvend server serves HTML pages to the client. Keeping these pieces
separate in my mind helped me quite a bit in deciding how to build a test
case for a feature I wanted to understand. (List members, please jump on
me here if I have misconstrued the interactions).


> I apologise once more for being a newbie just starting out with minivend, but
> frankly if the users group is not a forum where all users can ask questions,
> good or
> bad, then it's not worth being called a users group, and if everyone who can't
> spend
> tens to hundreds of hours can only get terse replies, then it's a very sorry
> affair.
I believe in three classes of sucessful minivend users at this time:

1. People prepared by thier backgound to do quick trial and error (eg,
Perl programmers)
2. People who have the minvend mindset 'naturally', ie they always
approach questions in a way well supported my the existant docs
3. People who spend tens to hundreds of hours.

I"m a firm '3', no doubt, and not quite sucessful yet, but not only do I
believe in open software, I have no money - so if more time is what it
takes, so be it. If I have to adjust my problem-solving skills, so be it.

> I also apologise for this long winded email, and if you all want me to leave
> then I
> will do just that, but it's a pity because minivend has so much potential.
> 
> Regards
> Roger
> 
I hope I have offered some encouragement. E-commerce is not easy; Minivend
is not easy. Both are possible.

Pat Santucci

-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list