I think any time you spend caching and uncompressing then loading
and cleaning the cache might void your delivery time savings.
Ideally, you'd want to use small elements just like you normally do
for browsers. Fast delivery of content. Delivering anything that
requires compression is simply too big to be throwing around (in your
sample - text! That's alotta text!)
Of course I have no idea in what context you would want to send them
a zipped file so you may very well be right. Part of my future stack
is to have an area with downloadable training videos - they will
likely be streaming which would be great if we could stream through a
"player". We'll have to wait on that one. But until then it may be
advantageous to zip these larger files that the user would likely be
willing to wait for (since people tend to know how big movies are)
My general comment about "put url" is that we can only use it
sparingly. I built a stack with a complete UI and a small number of
elements which all had to be downloaded from the web to start testing
"the future" of MetaCard over the web. Generally it was good put
MetaCard *will* skip many elements if it does not get a responce from
the server fast enough. I never had this problem if a call "put"
from a command line or button, but toss that puppy into a repeating
script engine designed to load up an entire card for an entire stack
and your going to see loads of missing elements. That's why I would
rather have a "set directory to URL", it's more efficient for
MetaCard programmers because it will take a boatload of work out of
your hands and likely be more robust that the single serving "put
url" command.
And on a related note, my stack had the option to cache or write the
files locally. So the end user could view the stack offline (after
they ran through the entire stack, say for another user). This saves
on their bandwidth but also means they *could* be prone to missing
updated information if I changed something on the sever.
All this is theoretical, I have a working stack with working script
with a UI. What I don't have is a target audience or any training
content. I'm testing the feasibility of using MetaCard as a closed
system for corporate training. Kind of like Placeware but a shitload
better (sorry, had to stress my point - Placeware sucks the bag).
As a group, we could all help in designing a good training stack, one
that allows for the teacher to use a stack to watch the progress of
his/her students as they go through a stack. They could then chat
with them if they are having problems, pop up a web page on the users
terminal. My god, I can't even begin to list the features I want to
put in this thing....
>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.
--
Cheers,
Simon
All your .com .net and .org domains for only $14.50 each.
Get them while they last... http://www.amigo-3.com/hosting/
--------------------------------------------------
"The great discoveries in science are not punctuated by 'Eureka! I've
found it!' but rather "Hmmm,that's funny...." Isaac Asimov
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.
