What about the posibility of serving gunziped data downloading it using the
methods you have discussed then unzipping it before displaying it. Example
put decompress(url "http://www.your-url-here.com/data.whatever.gz") into fld
"data". Depending on the format of the data this could save considerable
time.
>
> > 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.
>
>
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.
