One is immediately struck by the larger implications of this
"microcosm" of non-conflicting Rev tools and therefore the greater
significance of establishing these conventions.
<"blue sky" dream>
A single, universal "player" ala Acrobat Reader, suddenly goes "big
time" in terms of popularity "The RunRev Reader." Let's say we were
to feature this at our very hot page on our web site: http://
www.himalayanacademy.com/resources/... where I know, if we were to
feature such a standalone player, we would get between 2,000 and
10,000 downloads a month... not CNN to be sure, but also not
trivial...multiply this by say, 20 other web sites offering this same
player/reader....and imagine 200,000 people around the world, every
month = 1.4 million per year. Now this universal player has built
into it an index to an online library of stacks... not standalones.
Some free, some shareware, some demos for macho apps. Kagi could host
this stack inventory... kind of like versionTracker for Rev... Now
these "apps" (that do not carry the core engine...) are running in
the neighbourhood of from 15k widgets to 12Meg stacks with tons of
media...which could vary from trivial toys to serious stuff for Dad
like "Family Tax Manager" .....downloads and performance would be
incredible. In the face of the JAVA sloths worms deployed on the
web, this thing would be so alive... It would just dance! OK so,
users start "going nuts" as some apple users are over dash board
widgets...(they are indeed many of them super cool and useful at the
same time...) in no time at all some kid has 50-100 stacks on his
hard drive... all driven by this one player. OK so, he just starts
booting up all these stacks... he doesn't think to close them.. 20
minutes later... 15 stacks are up and running...
In this dream the rev namespace is no longer a trivial issue.
addendum to story: demand for the IDE skyrockets, Kevin and team
become millionaires, they hire legions of engineers, every bug is
fixed nightly and new builds are issued on a 72 hour cron...
</"blue sky" dream>
Anyway... I'm already there, in our little ocean of stacks here: I
find myself more and more resisting the impulse to build stand alones
and tell our people ("Get the Player"). It is so "sweet" to be able
to zip a stack, whose size drops down to some 25K, and send this as
an email attachment... Upgrades to stacks are a 10 second download...
upgrade to the player... once or twice a year, max...
I got my creator code from apple and so on Macs double clicking
stacks will boot my player... (still need to get my head around
windows doc/app binding) ...and I've deployed enough apps now that
run under this "Himalayan Academy Stack Player" that I already
starting to clobber my own globals and substacks. I had "Prefs" and
"Dev Notes" substacks all over the place... so, now I'm doing a 4
ltr prefix taken from the main stack name ATRA-Prefs, ATRA-Dev
Notes... but if you are working on conventions for this... I would
follow...
Richard, for those who were not at RevCon. where is the full ball
of wax? Andre gave me the files you shared at RevCon...
OK, down to earth again, to something real here:
gDateString... is already becoming too ambiguous where, for two
different running stacks, it may need two different values. Or the
even more ubiquitous "gFilePath"
If I understand the ECMI convention proposal correctly I should start
using a double prefix as in:
<Company="HAP"> Himalayan Academy Publications
# where do I go to register this officially with ECMI?
e.g. 1 <Main Stack Name= ATRA > Audio Transcriber.rev
e.g. 2: <Main Stack Name= PCAP> Photo Caption Writer.rev
What then does the global nameing convention become? (I do think
separators help readability)
gHAP_ATRA_FilePath
gHAP_PCAP_DateString
Am I close?
Yes, long and perhaps overkill in appearance, but I've enough grey
whiskers now that start twitching when anything (folder names, file
names, plans for web apps) go near the quicksand of ambiguity. I've
been burnt too many times... I don't mind doing this at all!
Sivakatirswami
p.s. can we consider changing the name of this thread?
On Jun 20, 2005, at 8:49 PM, Richard Gaskin wrote:
At present there are more dozens of prolific tool authors for the
Rev community, and the number grows every month. There are a
handful of issues with the development and deployment of tools that
are common to all, and by choosing to adopt a few fully-optional
rules about how things are put together we can collectively ensure
robust and reliable performance for all of them.
In the case of the ECMI recommendations this goes a step further
from simply not stepping on other tools to allowing graceful
integration of various tools.
One should ideally be able to tailor their workspace with tools
from any toolmaker, and expect that they'll all work without
conflict. This is full realizable with little effort.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
