>Alain: I avoid these too, but probably for different
>reasons. Users hate plugins. The download(s). The
>installation(s). The upgrade(s). Where to put then?
>When to upgrade them? Identifying the plugin as the
>culprit of buggy system behaviour, in the first place.
Alain,
any kind of plug-in would be yet another block in our stacks, so
downloading a plugin would not be needed. Still, it's too dangerous,
and as machine-specific compiled code is obviously
platform-dependant, it will be rarely needed in a web stack. And if
it is, they could save a FreeCard standalone on their server and use
it as a CGI or let the user download the stack or a tool stack
instead.
>Alain: Sound a bit like cookies. Client-side
>file-access limited to a designated location
>(file/folder) on the client's machine. The main hitch
>with cookies, for me, is that the user doesn't
>necessarily always use the same machine. Hence, his
>cookies don't follow him around. Thus, it is an
>un-reliable means of maintaining state.
This problem can only be solved by storing data on the server, which
has to be explicitly requested by the stack scripter to avoid a huge
security hole. But if a stack streamed over the web uses read/write
or similar commands, we will simply restrict it to one folder, so the
user's files aren't jeopardized.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
