[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
Re: MiniVend 4 (was MiniVend 3.15)
Quoting Kaare Rasmussen (kar@webline.dk):
> Do you have any time table in mind for MV 4? And on the same note, can
> you at this point tell something about what features it will contain
> and so on?
No time table. I suspect alpha releases will be out September or so,
with a beta release sometime later in the autumn. But these are only
suspicions. 8-)
Here is my working spec:
NOTE: ** already implemented *- partially done -- planned
HTTP layer:
** Selecting a catalog name in the URL, allowing one vlink/tlink
to access any number of catalogs.
-- mod_perl tlink program that will do "session snooping"
and deliver cacheable pages directly. In particular, this will
allow images to be delivered by MiniVend with low overhead,
a considerable feature for "virtual catalogs".
** Change the URL model from WuH7Axu8;arg;234 to a more standard
url?id=WuH7Axu8&mv_arg=arg&mv_pc=234. The old syntax will be
supported for compatibility of fixed links from partner sites.
** All variable names can be remapped both in and out, controlled
by a file. This allows you to sort of conceal the fact that it is an MV
catalog. Standard mapping includes the two-letter search variables, so
that:
<FORM ACTION="[process action=search]" METHOD=get>
<INPUT TYPE=hidden NAME=se VALUE=Americana>
<INPUT TYPE=hidden NAME=sf VALUE=category>
<INPUT TYPE=submit VALUE=Americana>
</FORM>
essentially is the same as:
[page scan
se=Americana
sf=category
] Americana [/page]
and
[page href=search form="
se=Americana
sf=category
"] Americana [/page]
The second one (scan) will still put the params in as file path
info, which is sometimes useful for search engine compatibility.
*- Much more HTTP-compliant internal web server, should eliminate
Mac issues with the internal web server (CRLF, etc.).
Action routing:
** All actions now supported (return, submit, refresh, etc.) are
supported, but can be mapped to any URL via mv_action=someaction.
Actions can still be overrode with [set ....] .
** User definable actions. You can map an action that calls severa
documented subroutines that perform user value save, basket update,
order addition, and autoloaded routines. The standard action set
will mimic MV3.0. You can override the default actions.
Programming:
*- Complete and reliable access to tags from all [perl] and [calc] routines,
i.e. $Tag->data( table => 'products', col => $col, key => $key ).
** Automatic mapping of values and scratch (i.e. $Value->{name},
$Scratch->{'Check out'})
*- Access to searches via programatic interface:
my $found = $LatestSearch->{matches};
$out = "Last search found $found items.\n";
my $limit = 5;
my $newsearch = $Tag->search( {
mv_searchspec => 'Americana',
mv_matchlimit => $limit,
} );
$out .= <<EOF;
New search found $newsearch->{mv_search_match_count} items.
<P>
EOF
$out .= $Tag->more_list();
** No more SQL search. All SQL-only queries are specified with
[sql ...], and the former sql search is of type 'db' with
preselection of = settings.
Sessions:
*- Sessions can be stored in files on a catalog-by-catalog
basis, and can be stored over NFS. This allows load-balancing
by running an MV catalog on multiple servers.
*- Better add-catalog/remove-catalog interface that will
allow catalogs to replicate to a different server for
load balancing; tied together with LDAP.
*- Configurable start values for certain variables. As an
example, the DefaultShipping tag will be replaced with
Value default mv_shipmode Ground
The keys are tied to locale, so that if you set:
Value en_UK mv_shipmode XPD
Value en_UK salestax_zone VAT
Scratch comes into play too:
Scratch en_UK mv_handling intl_surcharge
Configuration:
*- Configuration values can be specified with a subroutine.
*- minivend.cfg file can be stored in an LDAP directory.
Internationalization:
*- Time output will factor in locale (if available on the
machine)
-- Most error messages will be configurable for locale. No
translation is provided, but where possible a standard
system error message will be used.
Tags:
*- $$tag$$ is a synonym for [tag] inside other tags.
*- All lists are the same interface, and resemble a
search. This means you can do:
[loop search="
un=yes
ra=yes
tf=category
rf=category
"]
<H2>[loop-code]</H2>
[loop search="se=$$loop-code$$
ml=10
tf=price
to=r
rf=code,price,category"
label="$$loop-increment$$"
]
Title: [category-param title]<BR>Price: [category-param price]<BR>
[/loop]
[more-list label=$$loop-increment$$]
More [search-object param=mv_searchspec label=category]<BR>
[more]
[/more-list]
<P>
[/loop]
I don't know how efficient that would be; it depends on the
size of your database, but....
** To deal with the efficiency issues on code like the above,
a timed-build tag is added:
[timed-build minutes=60 file="config/category-list"]
...above code...
[/timed-build]
This builds the above list only every 60 minutes as measured
by file-modification time. To force a rebuild of all, just
remove all of the generated files. To prevent any rebuilds,
set seconds to a large number.
-- Many tags will be broken out into global UserTag definitions and
can be added/removed/changed as needed.
-- For compatibility with certain older tags, there will be
some UserTags in the distribution.
-- Many other changes too numerous to list here. In most possible
cases, backward compatibility is kept. The 3.12 demo catalog
tags should be there for the most part.
Debugging/logging:
-- debug interface eliminated and replaced with simpler one
-- logGlobal and logError can go to syslog
Database interface:
** New "session" database type allows you to create a small personal
database for a user. This can be saved to the "preferences" area via
userdb.
-- Procedure ties to database fields.
*- Integrated edit functions for administrators, ala Minimate.
Shipping:
** Each item can have a separate multiple shipmodes.
-- Zero-cost shipping optionally cause a next-best search.
*- Integrated US postal service lookup (if I believe I can get the right
data reliably)
Ordering:
** Complete control over batch ordering action. In particular, you
can batch select a set of items and display their current quantity
on a search. Separate items and aggregates can be mixed.
Reporting:
-- Multiple order reports -- mostly to isolate database updates
from the receipt file. You will be able to select whether it
tolerates failure and still sends the order or whether a failure
should stop order processing completely; this will be the
equivalent of a success->success->commit feature, with
very limited success->error->rollback.
Cleanup:
** "old" parser is completely eliminated, i.e. [[tag]] will
no longer work at all.
** All tag parameters named the same for similar functions, with
some aliasing for compatibility
** Eliminate
[if salestax ...]
[if shipping ...]
[if validcc ...]
[if pricing ...]
[if accessories ...]
** Eliminate the abstraction layer for of HTTP headers
** elimination of several tags
[description ...]
[last-page]
[finish-order]
[frames-on]
[frames-off]
[framebase]
[help]
[lookup]
[buttonbar]
[search]
[pagetarget]
[areatarget]
and catalog.cfg directives:
PriceCommas
ButtonBars
Help
CustomShipping
DefaultShipping
These are replaced by [process], but are aliased
[process-order]
[process-search]
[process-target]
Thinking about, but mostly in a place where I will need contributors:
-- Report generator. At one time I tried to integrate write() to
replace [row ..] [col ...], but as with most custom/overloading efforts
involving Perl's write() call and a non-standard file handle, it
failed. I may support an outside module.
-- POS hooks implemented via a standard interface. In particular, I would
like to have something that could generate a mime-tied attachement to
an order notification. At the simplest level, the receiving order
entry desk would click on it and update a spreadsheet. At a higher
level, there are many more possiblities. I have leads to three
accounting packages that might work well as a backend.
-- More load-balancing and footprint-reduction features. Notably, I would
like to share session configuration where possible, as having many
identical locale-translation and/or shipping tables eats a lot
of memory. Subcatalogs do this to some extent, but they are not
full-fledged MV citizens and are not satisfactory for this purpose.
-- Documenting tags with POD inside the module
This is probably a pretty good summary of the changes, though
you will all certainly be able to put in your two cents worth.
[disclaimer type=Obligatory]
There is no commitment to any of these features -- this is a plan and is
not yet wholly based in reality. 8-)
[/disclaimer]
--
Mike Heins http://www.minivend.com/ ___
Internet Robotics |_ _|____
Just because something is 131 Willow Lane, Floor 2 | || _ \
obviously happening doesn't Oxford, OH 45056 | || |_) |
mean something obvious is <mikeh@minivend.com> |___| _ <
happening. --Larry Wall 513.523.7621 FAX 7501 |_| \_\
