cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Polishing the flow contracts
Date Mon, 31 Mar 2003 09:08:27 GMT
Pier Fumagalli wrote:
> On 30/3/03 20:32, "Stefano Mazzocchi" <stefano@apache.org> wrote:
> 
> 
>>Pier Fumagalli wrote:
>>
>>>On 30/3/03 2:43 pm, "Stefano Mazzocchi" <stefano@apache.org> 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.


Mime
View raw message