Citát Yen-Ju Chen <[EMAIL PROTECTED]>:
> On 3/11/07, Isaiah Beerbower <[EMAIL PROTECTED]> wrote:
> > Thank you! That is all the encouragement I need to start work right away!
> > Do you like the names that I have used (task and workflow)?
> >
> > I personally like the name task, and also think that the app might be
> > initially named Workflow.app.
> > Please give any suggestions. (=
>
> Workflow.app sounds good to me and clear indicates what it is doing.
>
> >
> > Thanks Yen-Ju, that makes sense...
> > I haven't done anything with StepTalk before so I'll have to read up on
> > that.
> >
> > The workflow app, however, will probably only create Io code (as apposed
> > to other StepTalk languages) since my design relies heavily on Io's
> > features.
>
> To be clear, StepTalk is merely a framework.
> It can support any language if a language bundle is supplied.
> We have an unmaintained Io bundle for it.
Right. StepTalk is an abstraction over languages. Therefore, if you would like
to create any workflow in StepTalk, you need only the following:
- code or script of the step (what to do) in any language, you do not have to
care - the StepTalk interpreter has to care and engine for interpreting the
code/script should be available
- context or environment where the script or workflow step would be executed
The context is rougly a dictionary describing objects around you - what are
names of the objects that script can handle. Contexts can be stacked, each
context can have a parent context. That means that you can have following
stack:
- application context
- context for document 1
- context for document 2
- context for work flow 1 in document 2
- context for work flow 2 in document 2
I tried to make it as simple as possible. What else you might need?
The only difficulty that can arise is how to bind variable names in a language
to real objects from objective C runtime. In some languages it can be easy in
others not.
Example 1: You are creating a StepTalk bundle for language RaiseLanguage.
Fortunately, MyLanguage C API has a callback when interpreter reaches undefined
variable. You create a handler for the undefined variable, you bind it to the
object according to provided context and then make the interpreter continue.
Example 2: You are creating a StepTalk bundle for language WantItAllLanguage.
The language requires that you provide a table with list of all external
variables before execution. You pass the pointer to the table to a fuction you
use for interpreting a script. In this case, you take all objects from the
context, create the table yourself and pass it to the interpreter. Disadvantage
of this language is, that you do not have 'live' objects: if the 'current
document' becomes some other document during execution, interpreter will not
notice that.
There are many other possibilities...
How is it with Io interpreter API?
> If you only use Io, not StepTalk frameowork,
> it is harder to talk across several applications,
> say getting text from a mail in GNUMail.app
> and put it into a document in Typewriter.app.
> In this case, you need a public API from GNUMail and Typewriter.
> StepTalk provides a machenism for applications to publish their API
> and for script languages to access these applications.
> Anyway, when you start to work on your application, you will realize it.
> And maybe I am wrong. :D
The cross-application scripting was not finished in StepTalk - this was the
last
step needed for the 1.0 release :-) However, StepTalk is designed with this
cross-application environment in mind. If someone would be interested in
finishing it I can provide him with pointers to the code and more information.
Basically, the cross-application scripting was meant to be based on something
like remote-environments, separate processes or threads (in Workflow.app?) that
would handle remote scripting of applications and passing objects through
connections.
If you have any questions regarding StepTalk, just ask. Please add StepTalk to
the subject so I can identify the email more easily :-) thanks.
Stefan Urbanek
--
http://stefan.agentfarms.net
First they ignore you, then they laugh at you, then they fight you,
then you win.
- Mahatma Gandhi
> The bottom line is that your application can still create Io code in the
> end.
> But in order to have this script run, StepTalk is needed.
>
> Yen-Ju
>
> >
> > It sounds a good idea.
> > Here is my comment on the practical sides.
> > You need something to talk across different running applications.
> > Io itself is not enough. It only stays in the scope of individual
> > application.
> > Therefore, using StepTalk is a must-have, or something similar.
> > We do have an Io bundle for StepTalk before,
> > but the maintainer of StepTalk move to Mac.
> > Therefore, you may need to maintain StepTalk on the GNUstep-side.
> > The code of Io bundle for StepTalk still in Etoile's svn.
> > After you have Io bundle for StepTalk and StepTalk for GNUstep,
> > you need all the applications to support StepTalk.
> > It is easy and simple, but mostly unimplemented.
> > Once you have all of these, you are ready to go.
> > The chain of reaction is:
> > Io script -> StepTalk => several applications.
> >
> > Another thing to consider is to take an advantage of Services,
> > which Etoile want to use as much as possible.
> > Services is similar to your workflow, but only connects two
> application.
> > Nevertheless, the infrastructure is in GNUstep already.
> > We just need more service provider, and unfortunately, we don't have
> > a lot.
> > In this case, you can take an advantage of unix tool.
> > You just need to bundles them altogether.
> > Services may be a good place to start with.
> >
> > Yen-Ju
> >
> >
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
