[Zope3-dev] Re: WORKFLOW: Notes on WFMC and XPDL
Peter Mayne ap.spherion.com> writes: > The engine is written in Java. The previous version didn't have > persistence, which is a bit of a problem for a workflow engine. I added > it (using Hibernate) and gave the code to them, but I don't know if > they've incorporated it into the latest version of the engine. Yes, your initial implementation of persistence in YAWL using Hibernate was subsequently improved and it has been part of the YAWL engine for the last couple of years. Note that YAWL is now being used in "production" or "advaced pilot" by at least two companies. This should give some assurance that YAWL now has all the essential features to develop real applications on top of it. marlon ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Deprecations when interfaces changed (was Re: Re: Usage of IAnnotations disrespects interface declaration)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Maurer wrote:
> Christian Theune wrote at 2006-12-17 11:34 +0100:
>> ...
>> Jupp. Is there any technical chance the we can use the deprecation mechanism
>> or something like this to inform developers that they are not fully
>> complying to a changed contract?
>>
>> Still, for me it feels like the original interface should have included this
>> and I think it would be nice if we have an exit strategy for this (and
>> similar) situations where the original interface was wrong. I consider
>> the solution that introduce an additional interface in the long term to be
>> less than optimal. (Except if someone has a good explanation that I can
>> give to new developers why we made that distinction in the first place.)
>
> You can use the deprecation mechanism when you are ready to introduce
> a new interface and deprecate the use of the old one (i.e. generate
> a deprecation warning when an adapter is registered for the old interface).
>
> Generating a deprecation warning in the case when something does not
> provide/implement features newly introduced into the interface may
> be expensive: you need to explicitly check any object providing the interface
> whether it truely provides the added features as well.
>
> We might want to implement something like version numbers for interfaces
> in the future -- following the example of protocols ("HTTP/1.0" versus
> "HTTP/1.1"). Then a class/instance may declare that it implements interface
> "I" in version "V".
> Then, we may issue deprecation warnings, when a too old interface is
> used.
>
> Of course, adding version numbers to interfaces, is just a convention
> to introduce new (but related) interfaces.
We might be able to add a 'check-adapter-compliance' option to the
zope.conf, which would turn on the expensive test of conformance during
registration, and raise an exception if the interface failed to supply
all required names.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFhdId+gerLs4ltQ4RAjNvAJ4ogwrQkSDlgI+XhWehnURI6oHCvgCfTSIX
1GAzH+llVlDwNPJzJ09j1+M=
=xH/X
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Deprecations when interfaces changed (was Re: [Zope3-dev] Re: Usage of IAnnotations disrespects interface declaration)
Christian Theune wrote at 2006-12-17 11:34 +0100:
> ...
>Jupp. Is there any technical chance the we can use the deprecation mechanism
>or something like this to inform developers that they are not fully
>complying to a changed contract?
>
>Still, for me it feels like the original interface should have included this
>and I think it would be nice if we have an exit strategy for this (and
>similar) situations where the original interface was wrong. I consider
>the solution that introduce an additional interface in the long term to be
>less than optimal. (Except if someone has a good explanation that I can
>give to new developers why we made that distinction in the first place.)
You can use the deprecation mechanism when you are ready to introduce
a new interface and deprecate the use of the old one (i.e. generate
a deprecation warning when an adapter is registered for the old interface).
Generating a deprecation warning in the case when something does not
provide/implement features newly introduced into the interface may
be expensive: you need to explicitly check any object providing the interface
whether it truely provides the added features as well.
We might want to implement something like version numbers for interfaces
in the future -- following the example of protocols ("HTTP/1.0" versus
"HTTP/1.1"). Then a class/instance may declare that it implements interface
"I" in version "V".
Then, we may issue deprecation warnings, when a too old interface is
used.
Of course, adding version numbers to interfaces, is just a convention
to introduce new (but related) interfaces.
--
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Java applets and zope3
On Sun, 2006-17-12 at 10:40 +0100, Dieter Maurer wrote: > Paul Carduner wrote at 2006-12-12 22:59 -0800: > > ... > >load: class http://www.carduner.net/Programs/Fractals/Attractor.class not > >found. > >java.lang.ClassNotFoundException: > >http:..www.carduner.net.Programs.Fractals.Attractor.class > > ... > > at java.lang.Thread.run(Unknown Source) > >Caused by: java.io.IOException: open HTTP connection failed. > > Java tracebacks, too, are not so bad. > > As you can clearly see, the Java runtime tried to open an > HTTP connection and failed. > > The reason is probably that it tried the wrong server. Actually it looks like the problem is java sandbox security. An applet is in a restricted security zone (unless special privileges are granted). One of the restrictions is that an applet can only make a socket connection back to the same server that is hosting the applet. If I had to guess based on the java stacktrace I'd say the applet is trying to connecto to some third-party server. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] WFMC in core?
Hi, Adam Groszer wrote: > Hello Christian, > > It seems that the activity has the attribute, but it's not declared > in the interface. z.wfmc interface was/is quite out of sync with the > implementation I think. I already fixed some, but looks like there are > still some lurking. Any chance you want to pick that bug and assign it to you? Looks like you know that area of the code! -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Launchpad offer (Was: "Core" topic in Collector)
>> There are a few Launchpad developers in the Zope developer community, so >> I think there's a good communication channel there. Nonetheless, I >> would also like to offer the Zope Foundation Board phone and online >> access to the Canonical 24/7 support office for getting a quick response >> on any critical issues that are affecting use of Launchpad, while the >> Zope project is using Launchpad as its bug tracker. > > Yay! I guess that would be done by our single point of contact, right? I spoke to Jeff who runs the support department. What we usually do for commercial support is that two people in the customer's organisation are nominated as support contacts. So, for Zope, I expect the Zope Foundation Board would nominate one or two people as the support contacts for using Launchpad. The single point of contact for checking the quality of the bugs imported into the demonstration server can be a different person. > One question popped up for me: > > Are we talking about the Zope 3 collector or all collectors on > zope.org? > > Launchpad seems to give us even more benefit if we switched all > collectors over, because we would get the upstream management > capability. Right, the ability to have a bug filed on, say Zope 3, but then later retargetted to ZODB. > However, this is the zope3-dev list and I'm not sure we > could decide this for Zope 2 and ZODB. > > OTOH we could make a first step by switching with Zope 3 and let > everybody else join us in the mid-/longterm. > > I can also imagine that extending the discussion to CMF, Zope 2 and > the ZODB right now would render us inable to get to a decision within > the next days. > > My own conclusion on this is therefore that we should talk about the > Zope 3 collector only. I'm fine with this. Once the programming work is done, and we have a good mapping of the bugs' statuses in the Collector to the bug statuses in Launchpad, it will be straightforward to move the data from other Zope-related projects that use Collectors. So, the big issue there is seeing if this is a move that is supported by the community of people developing on these projects. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Launchpad offer (Was: "Core" topic in Collector)
Hi Steve, Steve Alexander wrote: > I hereby offer the services of a member of the Launchpad team at > Canonical to write Collector code if necessary in order to get an export > of bugs from the Collector in a format that can be imported into > Launchpad, to import said bugs into a demonstration server of Launchpad > so we can check that the data conversion is good enough, and to do an > actual import into the Launchpad production database, and to do this > during January 2007. This is a very generous offer! It meets my wish of not loosing collector data and Jim said he'd be happy just using launchpad. > There are a few Launchpad developers in the Zope developer community, so > I think there's a good communication channel there. Nonetheless, I > would also like to offer the Zope Foundation Board phone and online > access to the Canonical 24/7 support office for getting a quick response > on any critical issues that are affecting use of Launchpad, while the > Zope project is using Launchpad as its bug tracker. Yay! I guess that would be done by our single point of contact, right? > I'd appreciate a decision on this offer before Christmas, and preferably > sooner, so I can schedule the time before I leave on vacation. This means we'll have to find a decision within the next week. I'm +1 on this in general. One question popped up for me: Are we talking about the Zope 3 collector or all collectors on zope.org? Launchpad seems to give us even more benefit if we switched all collectors over, because we would get the upstream management capability. However, this is the zope3-dev list and I'm not sure we could decide this for Zope 2 and ZODB. OTOH we could make a first step by switching with Zope 3 and let everybody else join us in the mid-/longterm. I can also imagine that extending the discussion to CMF, Zope 2 and the ZODB right now would render us inable to get to a decision within the next days. My own conclusion on this is therefore that we should talk about the Zope 3 collector only. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Usage of IAnnotations disrespects interface declaration
On Sun, December 17, 2006 10:27 am, Dieter Maurer wrote: > Christian Theune wrote at 2006-12-11 08:30 +0100: >> ... >>> Both are not acceptable, especially option #1. We can't just change >>> existing contracts as we see fit. >> >>Right. However, I think it's possible to regard this is a bug in the >>original contract. > > But, some adapters for "IAnnotations" may not know about the newly > introduced responsibilities and fail to implement them. > > Thus, fixing this "bug" in the proposed way will introduce bugs > at other places. Jupp. Is there any technical chance the we can use the deprecation mechanism or something like this to inform developers that they are not fully complying to a changed contract? Still, for me it feels like the original interface should have included this and I think it would be nice if we have an exit strategy for this (and similar) situations where the original interface was wrong. I consider the solution that introduce an additional interface in the long term to be less than optimal. (Except if someone has a good explanation that I can give to new developers why we made that distinction in the first place.) Christian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Java applets and zope3
Paul Carduner wrote at 2006-12-12 22:59 -0800: > ... >load: class http://www.carduner.net/Programs/Fractals/Attractor.class not >found. >java.lang.ClassNotFoundException: >http:..www.carduner.net.Programs.Fractals.Attractor.class > ... > at java.lang.Thread.run(Unknown Source) >Caused by: java.io.IOException: open HTTP connection failed. Java tracebacks, too, are not so bad. As you can clearly see, the Java runtime tried to open an HTTP connection and failed. The reason is probably that it tried the wrong server. Use a TCP logger (e.g. "EtherReal") to understand what the client does on the network level. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Usage of IAnnotations disrespects interface declaration
Christian Theune wrote at 2006-12-11 08:30 +0100: > ... >> Both are not acceptable, especially option #1. We can't just change >> existing contracts as we see fit. > >Right. However, I think it's possible to regard this is a bug in the >original contract. But, some adapters for "IAnnotations" may not know about the newly introduced responsibilities and fail to implement them. Thus, fixing this "bug" in the proposed way will introduce bugs at other places. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] "Core" topic in Collector
Jim Fulton wrote at 2006-12-14 07:21 -0500: > ... >Yawn. IMO, the collect, despite it's flaws, isn't bad enough to >spend time on, especially given other priorities. OTOH, I'd be happy >to just switch to using Launchpad, which would require basically no >effort, especially if we don't bother transferring old collector data. It is not a good indication for "striving for quality" when problem data is taken out of sight... Of course, not transferring old collector data is less work, but so is not writing tests or documentation ;-) -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
