> The new "set directory to URL" is a feature that I (and likely
> others) have asked Scott to implement.
You can add my name to that growing list :)
> Basically you would build your stack and point
> to all the elements locally on your disk.
Do you mean that the element is not actually embedded in the stack. Instead you have a
pointer (URL) to the resource. Awesome! It will make MC stacks very tiny indeed.
Excellent for easy distribution. Excellent for updates.
> When your stack is ready, you can publish it to the web using a "set
> directory to URL" ...
My first impression was that one could set the directory so that all file commands
(save, read, write, etc) would use this location as their target. e.g. when you save a
file that is being edited or generated by MetaCard, it's automatically 'saved' to the
location pointed by the URL. Great for editing web sites served elsewhere, for example.
> ... and then the stack can be used by anyone on the net
> while the resources you used to build it are being called from a
> directory at a specified URL.
Excellent for load-balancing, too.
> The first implementation may require that you call the images
> directly from the server while building it...
Not a big deal.
> ... but I'm hoping that provisions will be made so we can build
> locally then using some type of "preference setting" toggle the
> set directory to point to either a local folder or to a desired URL.
That would indeed be a nice feature.
Relatively easy to script, though, if we get 'desperate'.
> So, instead of all your images or movies having the following as a
> filename "data/images/bony.gif" they would actually look like this
> "http://www.your-url-here.com/projectskull/images/bony.gif".
This is not one of the main reasons why this URL thing is hot, e.g. it is an easy
situation to handle, e.g. if the user downloads everything beforehand, in the form of
one archive that is auto-fetched by script.
> This way you can send out a runtime stack that loads the resources
> from your server as the viewer runs through the stack.
This OTOH is hot!
> Like me, you could build a MetaCard browser, this stack serves as the
> MC engine and is actually devoid of any information.
Netscape and Explorer, you ain't seen nothing yet !
> When the stack is run it looks at your server and checks to see
> if there are a list of other stacks, if so then it lists them.
> The user clicks on a stack (typically 16k) and it instantly opens
> on their desktop in runtime mode (due to the MC browser).
This is precisely what I need for my xCard Pantechnicon. Share it?
> When that stack opens it calls all the resources from the server.
> You are actually deploying stacks over the web in realtime!
This is really hot!
> For CBT developers this would be great as it allows for total control
> over the text and other elements in a stack (just like a browser
> there is only 1 repository). If you change an element on the server
> then all stacks running around the globe get the update
> the moment the stack calls it.
This is awesome.
> I'm telling you, MetaCard will really make it easy for us to deploy
> anywhere and still control our content. You can do this now but you
> really need to build a finely tuned script to keep track of all the
> resources being copied to the disk...
I'm sold on the idea, either way.
> (you may want the user to cache or actually store a copy
> as they run through your stack...
The infamous cache. It has caused me so many headaches in the past. My web sites are
constantly being changed even while users are using it. Bugs are rare but, when they
do occur, they have to be fixed ASAP but, if they don't empty their cache, then the
problem lingers longer than it needed to.
> depends on the content, such as large movies ...
Perhaps we could make the cache selective,
e.g. filter acording to size, type of media, etc.
> (why download more than once in a session)).
The cache is a good idea, especially with large media files, but let's make sure that
the cache is easy to empty, perhaps even allowing designers to remotely empty the
caches of their users. Why? Because they frequently neglect to do so, often complain
that it's buggy when it is no longer buggy, or don't even know what the cache is/does.
> Clear as mud?
Clear as day.
Alain Farmer
__________________________________________________________________
Get your own FREE, personal Netscape Webmail account today at
http://webmail.netscape.com/
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
