[kukeltje]

but of course some are more flawed than others....

If with flawed you mean more complex to realize end-to-end I agree. https almost always is end-to-end, smtp(s) almost never. Signing messages and/or encrypting overcomes this, but is difficult to enforce when responding. That is one of the reasons I think all this belongs outside jBPM. I myself are working (in the few lost ours I have) on an ebXML 2.0/3.0 b2b channel which is an additional one that for one reason or another is not hard to envision outside jBPM

[aapthorp]

Yes, that was what I was referring to. I agree that the channel specific handling is not a jBPM responsibility. However, the mapping to alternative standard forms or a canonical definition of data (i.e. not just java class definitions) for exchange over an ESB etc is something that might be included as helper functions. So client binding can be at the java API level or at the level of services exposed via an ESB etc...

[tom.baeyens]

"kukeltje" wrote:
Signing messages and/or encrypting overcomes this, but is difficult to enforce when responding. That is one of the reasons I think all this belongs outside jBPM.

"aapthorp" wrote:
Yes, that was what I was referring to. I agree that the channel specific handling is not a jBPM responsibility. However, the mapping to alternative standard forms or a canonical definition of data (i.e. not just java class definitions) for exchange over an ESB etc is something that might be included as helper functions. So client binding can be at the java API level or at the level of services exposed via an ESB etc...

I agree that it is not part of the core business of jBPM. But if we add such capabilities, then our users will be much more productive, and the solution that we offer will be much more attractive. Building in those channels into jBPM doesn't mean that you *must* use them. It only means that developers can save that time when selecting jBPM.

All those addons have to be related to our core business, which is state management. But they can really give the project a big boost, I think. I meet much more shops that have a hard time in getting technology to work, then companies like yours that know what they're doing. For the former type of companies, having such addons out of the box is a big deal (literally:-)

[kukeltje]

Building in those channels into jBPM doesn't mean that you *must* use them

Providing options to use them is still different to 'building in'. Just like the ESB did not build there flow engine themselves but use something externally developed library.

Having such addons out of the box is a big deal (literally:-)

Hmmmm... I do like DRY, but in this case I do want to.... having these additions out of the box does not mean we have to develop them ourselves.... That would be another DRY

[aapthorp]

I wonder if we can separate the channel discussion from the mapping between iCalendar and jBPM (inparticular TaskInstance). First for read and then for create / update...the semantics should be the same irrespective of channel (e-mail, HTTP, RSS, etc).

First mapping iCalendar properties to jBPM. I chose to map to VTODO (tasklist). The mapping of many properties is fairly obvious. As noted in my orginal post a few properties don't have obvious mappings:

DTSTART (scheduled start date)
LOCATION / GEO (location of task)
PERCENT (percent complete)
CATEGORIES (could map to task name?)
CLASS (privacy)
RESOURCES (I mapped actors to attendees)
STATUS (e.g. assigned, accepted, declined, etc)

So one obvious question is whether any of the above have equivalents in jBPM or do they point to extensions for jBPM? From Tom's earlier response it sounds like assignment state will be supported in 4.

As a matter of interest what have you intended for the task management module now shown in the jBPM 'architecture' graphic?

In looking at it the other way round (i.e. what can't be mapped from jBPM) the obvious question is how to deal with task specific variables? Are there any others? I can see three possibilities for task specific variables, an ATTACH (atttachment), embed them in the DESCRIPTION (currently only plain text) or 'X-' properties. Of course the question is how would a calendar user agent handle these? DESCRIPTION is fine for read only, but if we want to update? I was wondering with a XUL based UI such as Lightning / Sunbird if one could create task specific UIs that extend the basic calendar agent functionality...

[kukeltje]

I wonder if we can separate the channel discussion from the mapping between iCalendar and jBPM

Yes, good suggestion. Sorry for threadjacking ;-)

Personally, I'd wonder if DTSTART, LOCATION, PERCENT and CLASS can be left out for now. The task variables should be as easily readable as possible, so I'd not go for X- properties. Putting them in the description would also not be my favourite, so that leaves the ATTACH option or leave them out completely (at first). Additionally, I'd include a link somewhere that directly opens the task form page. For me that would be a near-perfect first release.

A XUL based ui could be nice, but why not just use the /a webbased page for updating?

[aapthorp]

Personally, I'd wonder if DTSTART, LOCATION, PERCENT and CLASS can be left out for now.

I agree that these may not be immediate requirements, but wonder if there are some missing requirements here...or some not so obvious mappings. For my purposes I used task variables for DTSTART and LOCATION.

The task variables should be as easily readable as possible, so I'd not go for X- properties. Putting them in the description would also not be my favourite, so that leaves the ATTACH option or leave them out completely (at first).

I need to look a bit further at the possibilities of ATTACH, for readonly purposes I formatted them into the description.

Additionally, I'd include a link somewhere that directly opens the task form page. For me that would be a near-perfect first release.

Yes, already done.

A XUL based ui could be nice, but why not just use the /a webbased page for updating?

That's certainly the short term approach, but what I'm thinking about here are the possibilities of providing task specific extensions to PIM type tools for both off-line and on-line useage. Or to put it another way how far does the iCalendar set of RFCs go to provide a standard Human Task protocol? Having just come across WS-HumanTask buried alongside BPEL4People I need to see how close the two compare...

[kukeltje]

For my purposes I used task variables for DTSTART and LOCATION.

that was my second thought to.

I need to look a bit further at the possibilities of ATTACH, for readonly purposes I formatted them into the description.

Most of the time the description will be to limited imo, so for a small number of variables it would work but not for many

[aapthorp]

Thought I'd just post a quick update on this...I got a bit side tracked with limitations of various user agents and also seeing what the potential was...

In addition to the basic capabilities to provide task entries (as a .ics) via http and handling task invitations via e-mail I've been playing with CalDav...having written a rather crude CaldDav server on top of jBPM. This allows me to update tasks directly via a calendar agent (e.g. Lightning). So I can mark a task as complete and jBPM fires the transition. This could easily be extended to create standalone tasks in jBPM if I added handling for externally created UIDs.

Having discovered Mozilla Lightning invite attendees window for tasks I've been trying to figure out how to support this...so manual task delegation can be done via the user agent.

The main issue I've had is the different capabilities of various user agents. My main test agents are Lightning, Kontact and Evolution. Lightning has Caldav support but, doesn't handle attachments or task/todo invitations. Kontact doesn't handle Caldav, but does handle attachment and task/todo invitations. Just checking out the latest version of Evolution.

I now to do some refactoring...before I can post something stable.