I really appreciate the effort to get this database
back on line. It is a
valuable resource and some continuation of it would be a great contribution
to the dance form. I have accessed it within the last year and found it
useful.
Owen's interface on line used very little of FileMaker's UI capabilities. I
doubt that you would lose much to move to another format. On the other hand
FileMaker Pro makes it very easy to update and maintain the database from
anywhere. It could be maintained by multiple people. Once you move to a
more "standard" database format the maintenance and expansion of the
database would be less accessible to folks without such technical
skills,...like me.
I suspect FileMaker Pro 4 was used because it was the first version that
allowed the easy publishing of a database on the Web. It is amazing how
quickly you can get a database on line with FileMaker Pro. I once built an
entire bug-tracking system and published it on line in four days using
FileMaker Pro!
I look forward to seeing what develops.
- Greg McKenzie
***************
On Tue, Jun 28, 2011 at 3:19 PM, Alan Winston - SSRL Central Computing<
winston(a)slac.stanford.edu> wrote:
William wrote:
It looks like FileMaker4 dates from somewhere
around 1997 to 1999.
(The current version is FileMaker 11.) I can see that Russell would
have tired of supporting a database in an old software package on an
old machine. It definitely seems like the right answer would be
migration to a standard database and scripting language, like MySQL
and PHP or Python. Mind, the advantage of FileMaker seemed to be ease
of UI creation, and PHP would instead tie one into deep realms of
database access.
It seems like you'd be looking at a fairly standard CRUD with a single
record
per entry. (I've had some dreams about an online dance presentation that
allows commentary, like the Talmud, so you have the source and then people
can
describe teaching tips, etc. But that's really feature creep for what
you're
talking about.) I don't think very deep realms of database access come
into
play - I don't think you necessarily even need a multi-table join. You
could
pretty much find sample PHP code for CRUD and adapt it; it wouldn't be a
big
deal.
I'm due to find out more about the
discussions at CDSS some time next
week. Ideally, the ACDOL material could pour directly into a new
database, but setting one up would take some time. Depending on what
I hear, perhaps it'd be possible and useful to get the ACDOL material
on-line in a read-only form in the mean time... Hmmm... Perhaps just
formatting it, and bagging the database functions could serve that
end. With fewer than 300 entries, a page for each dance and an index
might even suffice. That'd be a lot faster to set up than an entire
web-enabled database.
You could add some extra value if you had multiple index
pages (which you
could generate automatically, I think, while extracting the individual
pages);
index by title, index by title within formation, index by title within
author,
index by title within difficulty level.
But this may be too much to do if the contents can just be poured into
whatever
CDSS is doing. (And isn't CDSS doing some fabulous stuff on the web these
days!) If you wanted to do something tomorrow, you could just extract to
Excel
(or, say, |-delimited ASCII) and let people import it and sort and search
to
their heart's content.
All since you asked for thoughts.
-- alan
===============================================================================
Alan Winston --- WINSTON(a)SSRL.SLAC.STANFORD.EDU
Disclaimer: I speak only for myself, not SLAC or SSRL Phone:
650/926-3056
Paper mail to: SSRL -- SLAC BIN 99, 2575 Sand Hill Rd, Menlo Park CA
94025
===============================================================================
_______________________________________________
Callers mailing list
Callers(a)sharedweight.net
http://www.sharedweight.net/mailman/listinfo/callers
_______________________________________________
Callers mailing list
Callers(a)sharedweight.net