openflow-dev

[Openflow-dev] CVS now ok !

[Vincenzo Di S. <e.d...@ic...>]

Hi all,
it seems we`ve fixed all CVS problems now.
Bye,
	Vincenzo.

-- 
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.d...@ic...              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588

Re: [Openflow-dev] Subflows and loops

[Vincenzo Di S. <e.d...@ic...>]

I don`t know why, but we have problems with sourceforge cvs, we cannot=20
commit the new changes, hope this will be fixed soon.

Juli=E1n Mu=F1oz Dom=EDnguez wrote:

> Hi Vincenzo,
>=20
>=20
>>>I don't see how to do a sub-workflow.
>>>
>>
>>The activity creation form has a section that let you choose if you
>>activity has to be a "subflow" and the type of subflow.
>>
>=20
> I don't have this.
> Is it in the tar.gz, or in the cvs
>=20
> (The cvs version is causing this error on my Zope
> bootup, and doesn't work.
>=20
> 2001-12-29T18:21:56 ERROR(200) Zope Could not import Products.OpenFlow
> Traceback (innermost last):
>   File /home/julian/Zope/lib/python/OFS/Application.py, line 558, in
> import_product
>   File /home/julian/Zope2/lib/python/Products/OpenFlow/__init__.py, lin=
e
> 1, in ?
>   File /home/julian/Zope2/lib/python/Products/OpenFlow/openflow.py, lin=
e
> 8, in ?
>     (Object: Folder)
> ImportError: No module named process
> )
>=20
>=20
>=20
>=20
>=20
> A "subflow" is an activity which is a workflow, correct ?
>=20
>=20
>=20
>=20
>=20


--=20
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.d...@ic...              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588

Re: [Openflow-dev] Subflows and loops

[<jm...@so...>]

Ah, ok, I see it now.

process.py is missing from the cvs. Copying the one whis is on 0.5 tgz
allows openflow to start


On Tue, 1 Jan 2002, Juli=E1n Mu=F1oz Dom=EDnguez wrote:

>
> Hi Vincenzo,
>
> > > I don't see how to do a sub-workflow.
> >
> >
> > The activity creation form has a section that let you choose if you
> > activity has to be a "subflow" and the type of subflow.
>
> I don't have this.
> Is it in the tar.gz, or in the cvs
>
> (The cvs version is causing this error on my Zope
> bootup, and doesn't work.
>
> 2001-12-29T18:21:56 ERROR(200) Zope Could not import Products.OpenFlow
> Traceback (innermost last):
>   File /home/julian/Zope/lib/python/OFS/Application.py, line 558, in
> import_product
>   File /home/julian/Zope2/lib/python/Products/OpenFlow/__init__.py, line
> 1, in ?
>   File /home/julian/Zope2/lib/python/Products/OpenFlow/openflow.py, line
> 8, in ?
>     (Object: Folder)
> ImportError: No module named process
> )
>
>
>
>
>
> A "subflow" is an activity which is a workflow, correct ?
>
>
>
>
>

--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

Re: [Openflow-dev] Subflows and loops

[<jm...@so...>]

Hi Vincenzo,

> > I don't see how to do a sub-workflow.
>
>
> The activity creation form has a section that let you choose if you
> activity has to be a "subflow" and the type of subflow.

I don't have this.
Is it in the tar.gz, or in the cvs

(The cvs version is causing this error on my Zope
bootup, and doesn't work.

2001-12-29T18:21:56 ERROR(200) Zope Could not import Products.OpenFlow
Traceback (innermost last):
  File /home/julian/Zope/lib/python/OFS/Application.py, line 558, in
import_product
  File /home/julian/Zope2/lib/python/Products/OpenFlow/__init__.py, line
1, in ?
  File /home/julian/Zope2/lib/python/Products/OpenFlow/openflow.py, line
8, in ?
    (Object: Folder)
ImportError: No module named process
)





A "subflow" is an activity which is a workflow, correct ?




--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

Re: [Openflow-dev] usability Openflow 5.0

[Vincenzo Di S. <e.d...@ic...>]

Juli=E1n Mu=F1oz Dom=EDnguez wrote:

> In general I like Openflow 5.0, but I have seen some problems for the "=
day
> to day":
>=20
> Now the applications are in a separate tab. Here we could have, say, 40
> applications: it would be nice to see the "Tittle" (a commment) about t=
his
> application.


Yes it`s a good idea.


> The same for activities: but maybe there is no space ??? But what is mo=
re
> important from a point of view os usability, see the tittle, or see if =
the
> activity is XOR or AND (not sure myself, what do you think?)


IMO, we should give all the informations about the objects. For the=20
moment we aren`t paying attention on the templates, because our priority=20
now is the code, so they may appear incomplete or not well structured.

=20
> And now, the biggest usability problem (in my case):
>=20
> With previous I had a problem with the names:
> To avoid problems, I had to give a different name to the Activity and t=
o
> the URL of the application (the method).
>=20
> Now with Openflow 5.0 I have also to "invent" a name for the
> application...
> I have to invent 3 names: the activity, the application, and the
> called method name.
>=20
> In practice it would be much more easy if I could use the same name.
>=20
> Illuminate me, maybe it is not a problem now with the new object model =
??

You can give the same name to the differt objects, because they`re URLs a=
re usually different, but this may cause confusion
when you need to maintain your workflow application. Try appending suffix=
 as "abc_activity" or "abc_app" etc...


--=20
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.d...@ic...              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588

Re: [Openflow-dev] Subflows and loops

[Vincenzo Di S. <e.d...@ic...>]

Juli=E1n Mu=F1oz Dom=EDnguez wrote:

> Hello team, :)
>=20
> "OpenFlow will support subflows and loops in the next release."
>=20
> Are they supported in 0.5 ?


Yes :)

> I don't see how to do a sub-workflow.


The activity creation form has a section that let you choose if you activ=
ity has to be a "subflow" and the type of subflow.


The loops are supported in a natural way, now you can link back two or mo=
re activities with transactions and the process history will be coherent.


--=20
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.d...@ic...              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588

Re: [Openflow-dev] usability Openflow 5.0

[<jm...@so...>]

0.5, not 5.0 :-)

[Openflow-dev] usability Openflow 5.0

[<jm...@so...>]

In general I like Openflow 5.0, but I have seen some problems for the "day
to day":

Now the applications are in a separate tab. Here we could have, say, 40
applications: it would be nice to see the "Tittle" (a commment) about this
application.

The same for activities: but maybe there is no space ??? But what is more
important from a point of view os usability, see the tittle, or see if the
activity is XOR or AND (not sure myself, what do you think?)

And now, the biggest usability problem (in my case):

With previous I had a problem with the names:
To avoid problems, I had to give a different name to the Activity and to
the URL of the application (the method).

Now with Openflow 5.0 I have also to "invent" a name for the
application...
I have to invent 3 names: the activity, the application, and the
called method name.

In practice it would be much more easy if I could use the same name.

Illuminate me, maybe it is not a problem now with the new object model ??


--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

[Openflow-dev] Subflows and loops

[<jm...@so...>]

Hello team, :)

"OpenFlow will support subflows and loops in the next release."

Are they supported in 0.5 ?
I don't see how to do a sub-workflow.


--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

Re: [Openflow-dev] Calling a dtml-method

[Daniele T. <d.t...@ic...>]

Ok! We'll put the eval_parameters['client'] right back! Thanks a lot for =
the=20
explanation!

Daniele =3D)


On Thursday 20 December 2001 22:30, Juli=E1n Mu=F1oz Dom=EDnguez wrote:
> On Thu, 20 Dec 2001, Daniele Tarini wrote:
> > You are right, we skipped the 'client' parameter.
>
> I am talking about this case:
>
> - automatic activity
> - the called method is acquired, outside the Openflow folder
> - This method is a DTML-Method
> - This method acquires something, in the way you expect (Zope acquisiti=
on,
> it fetchs the methods, and the properties in the parent folder of the
> DTML-methon, then in the parent of the parent folder... etc...).
>
>
> What I had without the "client" parameter, was an error. While this met=
hod
> worked in manual mode (calling it from the ToDoList), it failled in
> automatic. I think that the DTML was acquiring from the Activity folder=
,
> and that is why it failed.
>
> Well, looking the Zope code, I setted "client" to the parent
> folder, and it worked.

[Openflow-dev] Feature idea: printed messages

[<jm...@so...>]

When automatic activities are executed, you lose the printed
messages they generate, and get only the one of the calling activity.

It would be nice to store the returned value of the activity (how, I
don't know), so you could do a "print token.move(..)" (or
print activity.movetoken(..)" in the previous activity.

An extension would be to allow this with several cascaded automatic
activity.


--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

Re: [Openflow-dev] Apply

[Vincenzo Di S. <e.d...@ic...>]

Yes :)

Juli=E1n Mu=F1oz Dom=EDnguez wrote:

> On Thu, 20 Dec 2001, Daniele Tarini wrote:
>=20
>=20
>>PS: Juli=E0n, did you notice we used the apply function like you sugges=
ted?
>>Thanks again for the contribution...
>>
>=20
> Do you agree that is the nicest way to give the parameters to called
> methods ? :)
>=20
>=20
>=20


--=20
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.d...@ic...              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588

Re: [Openflow-dev] Calling a dtml-method

[<jm...@so...>]

On Thu, 20 Dec 2001, Daniele Tarini wrote:


> You are right, we skipped the 'client' parameter.
>
> The reason for keeping a 'client' parameter is not clear to me... is it f=
or
> your use or for Zope? I tried putting a document in the same folder the D=
TML
> is in, a property (with the same name, of course) both in OpenFlow and in=
 the
> Process: what I got is that the referred item is the DTML in the same fol=
der
> the application DTML is in. So it seems that the context is the applicati=
on
> DTML parent. Isn't this the behaviour you wanted? I might have got someth=
ing
> wrong: do you mind explaining again?
>
> Maybe you are referring to the automatic start of application on an
> auto-start activity?


I am talking about this case:

- automatic activity
- the called method is acquired, outside the Openflow folder
- This method is a DTML-Method
- This method acquires something, in the way you expect (Zope acquisition,
it fetchs the methods, and the properties in the parent folder of the
DTML-methon, then in the parent of the parent folder... etc...).


What I had without the "client" parameter, was an error. While this method
worked in manual mode (calling it from the ToDoList), it failled in
automatic. I think that the DTML was acquiring from the Activity folder,
and that is why it failed.

Well, looking the Zope code, I setted "client" to the parent
folder, and it worked.



--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

[Openflow-dev] Apply

[<jm...@so...>]

On Thu, 20 Dec 2001, Daniele Tarini wrote:

> PS: Juli=E0n, did you notice we used the apply function like you suggeste=
d?
> Thanks again for the contribution...

Do you agree that is the nicest way to give the parameters to called
methods ? :)


--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

Re: [Openflow-dev] Calling a dtml-method

[Daniele T. <d.t...@ic...>]

On Wednesday 19 December 2001 16:00, Juli=E1n Mu=F1oz Dom=EDnguez wrote:
> Vincenzo, and Daniele,
>
> in Openflow 0.5, what is the context when you call automatically a
> dtml-method ? In previous versions, without
> evalparameters['client']=3Dfunc.aq_parent (namespace given to the calle=
d
> method), the dtml-method acquired the variables from the activity folde=
r,
> not from his parent folder in the Zope tree, which I think it is not th=
e
> "natural way".
>
> In a first glace, I don't find the equivalent to
> evalparameters['client']=3Dfunc.aq_parent in Openflow 0.5


You are right, we skipped the 'client' parameter.=20

The reason for keeping a 'client' parameter is not clear to me... is it f=
or=20
your use or for Zope? I tried putting a document in the same folder the D=
TML=20
is in, a property (with the same name, of course) both in OpenFlow and in=
 the=20
Process: what I got is that the referred item is the DTML in the same fol=
der=20
the application DTML is in. So it seems that the context is the applicati=
on=20
DTML parent. Isn't this the behaviour you wanted? I might have got someth=
ing=20
wrong: do you mind explaining again?

Maybe you are referring to the automatic start of application on an=20
auto-start activity?


Daniele =3D)

PS: Juli=E0n, did you notice we used the apply function like you suggeste=
d?=20
Thanks again for the contribution...

[Openflow-dev] Calling a dtml-method

[<jm...@so...>]

Vincenzo, and Daniele,

in Openflow 0.5, what is the context when you call automatically a
dtml-method ? In previous versions, without
evalparameters['client']=3Dfunc.aq_parent (namespace given to the called
method), the dtml-method acquired the variables from the activity folder,
not from his parent folder in the Zope tree, which I think it is not the
"natural way".

In a first glace, I don't find the equivalent to
evalparameters['client']=3Dfunc.aq_parent in Openflow 0.5

--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

[Openflow-dev] User Management

[<jm...@so...>]

On Wed, 19 Dec 2001, Vincenzo Di Somma wrote:

> The fact is that CMF has a very convenient view on a lot of open
> problems for OpenFlow: user management, content management, separating
> functionality from usage and so on.

About User Management.

It would be an interesting feature that an automatic activity could
acquire some roles, or become a diferente user (ie admin, or
another).

I have solved this calling a python script with a proxy role set to
"Manager", and passing it a password parameter from the openflow. And only
openflow should know this password.

But that's not very secure, imagine there is and error, the user could see
the password in the traceback (I read in Zope mail-list that even in "no
debug mode", the traceback appears in the html-code, but is not displayed
in the browser).

There is maybe another cleaner way of doing it ?


--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

Re: [Openflow-dev] Openflow -> CMF

[Vincenzo Di S. <e.d...@ic...>]

I don`t know exactly what we`ll do probabily we`ll separate the two=20
repositories. But it`s just my personal idea, for the moment.
However is our intention to obtain with the 0.6 release a good and=20
stable workflow tool so all users who don`t want to use CMF for the=20
moment, will have a good workflow support, and all products developed=20
till now will work well.


Juli=E1n Mu=F1oz Dom=EDnguez wrote:

> On Wed, 19 Dec 2001, Vincenzo Di Somma wrote:
>=20
>=20
>>We`ll freeze the stand alone development after the 0.6 release.
>>If someone will want to take over OpenFlow when it will migrate to
>>CMF... we'll be glad to help and contribute on the development.
>>
>=20
> Ok very interesting. Who knows, maybe people (including me) interested =
in
> Openflow will install CMF for this reason :-)
>=20
> Ok, it is cool to have this clear. The idea is for not loosing this las=
t
> "CMF non-dependant" product. Then me, or someone else, could maintain i=
t,
> maybe in another sourceforge developpment group ? Just in case the CMF
> dependant product isn't satisfactory for own use... Who knows, we don't
> close this possibily, ok ??
>=20
> In theory CVS supports this "multibranch" feature, but then I suppose a=
ll
> must be maintained in the same sourceforge developpment group. (But is =
it
> a good /real possibility ?)

>=20
> Uhmm, or will it all be migrated to the CMF CVS ??
>=20
> And then, how could independant cvs feeds easily with the new features
> added in OpenFlow-CMF ?
>=20
>=20
>=20


--=20
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.d...@ic...              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588

Re: [Openflow-dev] OpenFlow 0.5 and future development

[<jm...@so...>]

On Wed, 19 Dec 2001, Vincenzo Di Somma wrote:

> 1) The discussion about the OF migration to CMF has taken place in the
> CMF mailing list... this has been necessary since we wanted no
> duplication of mails on both lists. This might not have been too wise:
> sorry :(

Vincenzo, and Daniele: congratulations for this developpment, Openflow is
really Cool, and 0.5 looks cooler. Nothing to say, it was just that I am
always interested in your comments about Openflow.



> 2) We presented a road map for future OF development on the OF mailing
> list. We got no replys to the road map about the CMF migration...

All you do and decide for developping Openflow is good.

> developing as we are doing. Besides, we do have a boss (ehm, "manager")
> that directs us and some of the decisions come directly from him...

He or she is a good boss :-)

--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

[Openflow-dev] Openflow -> CMF

[<jm...@so...>]

On Wed, 19 Dec 2001, Vincenzo Di Somma wrote:

> We`ll freeze the stand alone development after the 0.6 release.
> If someone will want to take over OpenFlow when it will migrate to
> CMF... we'll be glad to help and contribute on the development.

Ok very interesting. Who knows, maybe people (including me) interested in
Openflow will install CMF for this reason :-)

Ok, it is cool to have this clear. The idea is for not loosing this last
"CMF non-dependant" product. Then me, or someone else, could maintain it,
maybe in another sourceforge developpment group ? Just in case the CMF
dependant product isn't satisfactory for own use... Who knows, we don't
close this possibily, ok ??

In theory CVS supports this "multibranch" feature, but then I suppose all
must be maintained in the same sourceforge developpment group. (But is it
a good /real possibility ?)

Uhmm, or will it all be migrated to the CMF CVS ??

And then, how could independant cvs feeds easily with the new features
added in OpenFlow-CMF ?


--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

Re: [Openflow-dev] OpenFlow 0.5 and future development

[Vincenzo Di S. <e.d...@ic...>]

Juli=E1n Mu=F1oz Dom=EDnguez wrote:

> On Tue, 18 Dec 2001, Vincenzo Di Somma wrote:
>=20
>=20
>>Every suggestions are welcome :)
>>
>=20
> Why isn't this mail-list used to talk about the developpment ?
>=20
> Or are the you all (icube, and people developping CMF) groups of
> developpers in an office (direct oral communication, the better:-)


There are at least three consideration you have to take in account:

1) The discussion about the OF migration to CMF has taken place in the=20
CMF mailing list... this has been necessary since we wanted no=20
duplication of mails on both lists. This might not have been too wise:=20
sorry :(

2) We presented a road map for future OF development on the OF mailing=20
list. We got no replys to the road map about the CMF migration...

3) Actually the main developers of OF (Vincenzo Di Somma and Daniele=20
Tarini) do work in the same place (Icube) and on the same keyboard (pair=20
programming! :) A lot of discussions are taken orally. Tough we are=20
willing to share all the decision making to anybody interested in=20
developing as we are doing. Besides, we do have a boss (ehm, "manager")=20
that directs us and some of the decisions come directly from him...

=20


--=20
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.d...@ic...              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588

Re: [Openflow-dev] OpenFlow 0.5 and future development

[Vincenzo Di S. <e.d...@ic...>]

Peter Simmons wrote:

>>I would like that OpenFlow could still exist as a separate product,
>>without CMF dependencies.
>>
> 
> OpenFlow should still be able to exsist as a seperate product when it is CMF
> dependant because all you are adding are the CMF API methods so that CMF can
> interact with it and vis-versa,
> 
> If that is not going to be the case how come?


Unfortunately this is not so. CMF product architecture is a lot 
different from an actual Zope product architecture: it is not just a 
matter of APIs.

Many functionality of OpenFlow will be rewritten using CMF APIs since 
they are more... appropriate for what OF has to do.


-- 
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.d...@ic...              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588

Re: [Openflow-dev] OpenFlow 0.5 and future development

[Vincenzo Di S. <e.d...@ic...>]

Juli=E1n Mu=F1oz Dom=EDnguez wrote:

> This are very good news !!
>=20
> I would like that OpenFlow could still exist as a separate product,
> without CMF dependencies.
>=20
> Will it be possible ??


We`ll freeze the stand alone development after the 0.6 release.
If someone will want to take over OpenFlow when it will migrate to=20
CMF... we'll be glad to help and contribute on the development.

=20
> The idea is that it must be clear what product is CMF dependent, and wh=
at
> not, and say "From here it is CMF dependent", and "in this cvs branch i=
s
> the CMF independent product".


OpenFlow 0.6 will be the last release as a Zope product: this is our=20
firm intention and if nothing goes wrong we'll stick to this.

The fact is that CMF has a very convenient view on a lot of open=20
problems for OpenFlow: user management, content management, separating=20
functionality from usage and so on.

And then Zope itself is strongly migrating to CMF and we want to catch up=
 :)



--=20
Vincenzo Di Somma - Responsabile Ricerca e Sviluppo - Icube S.r.l.
Sede:   Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: e.d...@ic...              WWW: www.icube.it
Tel:    (+39) 050 97 02 07              Fax: (+39) 050 31 36 588

[Openflow-dev] Problem with cvs in sourceforge

[<jm...@so...>]

Why have I this error ?


[julian@julian cvs]$ export CVS_RSH=3Dssh
[julian@julian cvs]$ cvs -z3
-d:ext:jul...@cv...:/cvsroot/openflow co
openflow-engine
jul...@cv...'s password:
Could not chdir to home directory /home/users/j/ju/julian69: No such file
or directory
/usr/bin/X11/xauth:  error in locking authority file
/home/users/j/ju/julian69/.Xauthority
cvs [server aborted]: can't chdir(/home/users/j/ju/julian69): No such file
or directory


--=20

      __o
    _ \<_
   (_)/(_)

Saludos de Juli=E1n
EA4ACL
-.-

Re: [Openflow-dev] OpenFlow 0.5 and future development

[Peter S. <pe...@bc...>]

> I would like that OpenFlow could still exist as a separate product,
> without CMF dependencies.

OpenFlow should still be able to exsist as a seperate product when it is CMF
dependant because all you are adding are the CMF API methods so that CMF can
interact with it and vis-versa,

If that is not going to be the case how come?

Regards,
Peter Simmons