On 30/3/03 20:32, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
Pier Fumagalli wrote:
On 30/3/03 2:43 pm, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
Here is what I would like to see:
1) no functions without an object namespace. This is to imply that all non-prefixed functions belong to the flow. Provides coherent cognitive context.
I don't understand that.... What do you mean by "function with(out) object namespace?
I mean functions without an object up front.
info() <- bad log.info() <- good
Ah... Ok, gotcha...
Now, you realize that "info()" can also be called as "this.info()", right?
right, but all my other flow methods are as well. what i want is to suggest a mental association between
this./nothing -> your flow stuff
cocoon/log -> our stuff
* -> other objects that either you or flow blocks provide
So, you are implying that you want the basic class of the "script" object not to expose any method, much like an empty interface...
Exactly.
So, the only thing we should expose are 3 read only properties:
cocoon: an instance of Cocoon log: an instance of Log flow: an instance of Flow
yes
4) the following functions
Flow Object: flow.import() -> imports another flowscript
Hmmm... Should we allow cross-language (when/if we're going to have it) flowscripts interaction? Because otherwise I'd prefer a name such as "interpreter"....
I don't get it. What's wrong with the name flow?
"Flow" in my mind is the whole kit and caboodles: it's the "Cocoon Flow", a set of API to do something.
The "Flow" in my mind is made up by: - "Cocoon", an interface to talk to the cocoon internals - "Log" the logging facility - "Interpreter" whatever executes our script - Other objects (such as "Continuation") which instances we can get from the three above mentioned instances...
"Flow" is tha package (IDL module), "Interpreter" is the connection to the scripting engine...
Yes, I see your point, but 'flow' in my mind is the instance of the entire concept that handles my flow. So
flow.import()
means that I'm adding another information to my flow. The fact that this flow is implemented with a javascript interpreter is, in fact, unimportant.
Suppose future allows us to write the flow directly in java and that a future JSR adds continuations as native objects in java: would it be sane to call
interpreter.import()
at that point?
Flow is totally abstracted already, as a concept, from the underlying implementation and the semantics of our FOM should keep suggesting that.
Cocoon Object: cocoon.sendPage(uri, dict) -> sends a pipeline to the client
cocoon.sendPageAndWait(uri, dict) -> sends a pipeline to the client and save the continuation.
cocoon.process(uri, dict, output
Stefano... This one was cut as well... Can you please forward the rest????
Oh, #$&*! No, i can't, that message wasn't stored in my sent folder :/
grrrr
I hate these things.
Use Entourage or Apple Mail on your OS/X box! :-) :-) :-)
I'm sooooo used to mozmail shortcuts... and spam filtering works so well and you don't allow me to install spambayes on pulse! :(
but there is hope: they are workign on a stripped-down version of mozmail to go along with phoenix/camino... hopefully with native widgets instead of that super-heavy XUL stuff.
besides, I think it's not a problem with mozmail but my stupid router that cuts my connections... but hopefully I'm going to be out of here soon.
Stefano.
