At 2:27 PM -0800 on 11/29/99, Alain Farmer wrote:
>> Alain: This new OpenTalk syntax was inspired from
>> AppleScript's favorites feature, but my spin has
>> nothing to do with MacOS favorites or with Web
>> bookmarks.
>
>> Anthony: The problem is that your syntax will only
>> allow paths ...
>
>Alain: What makes you say this ??
>
>Anthony: Because you're defining a property which
>stores search paths, correct?
>
>Alain: Yes, I am defining a property which stores
>search paths but does this necessarily exclude other
>path-like references (like URLs for example) ? The
>script property is quite liberal with its contents.
Yes, it does exclude them, because you'd have to engine interpret the property.
BTW: I hadn't even though of web search paths... There are far more methods
to search than anyone writing the engine can dream up.
>
>> Alain: How much limited script space (chars) are
>> going to be occupied by this search-feature?
>
>Anthony: First off, THERE IS NO 30K LIMIT. There is
>not a problem with limited script space, period.
>
>Alain: Is the limit raised (to 64K like MC, for
>example) or is there no limit whatsoever?
There will be a limit -- of 4GB, which we'll raise if we ever need to :)
>
>Anthony: Second, these script should be but a few
>lines, I'd guess. (HANDLER) This would, btw, be the
>built-in algorithm.
>
>Alain: So you agree then that part of the search-paths
>process should be internal to the application ...
I say that it might be a good idea to have a built-in one. But it would
only be used if the message reached NuCard, sort of like the domenu handler.
>Alain: ... with internal defaults for the externalized
>portion of the search-paths process, just in case the
>user misuses or deletes the Home-stack-handler(s) that
>manage it. Great!
So can we agree on:
3 properties of NuCard* for storing stack, application, and document
search paths
NuCard:FindStack, NuCard:FindApp, NuCard:FindDoc which are functions
taking the name of the stack, app, or doc, and returning a path to
it.
NuCard will have defaults for the three functions above. The default
behavior will be a simple search through all of those directories
to find the stack, and return the first one found.
NuCard will be responsible for restoring and saving the three paths
properties in a manner sane for the implementation it's running on,
such as a prefs file on a Mac/Windows box, or config. files on Unix
boxen.
*since we can't call it OpenCard anymore
>
>Anthony: And there I go informally proposing syntax
>again.
>
>Alain: What's wrong with that ?
Nothing :)