John, Thanks for the hints and ideas! As far as I can see the HttpDispatcher doesn't really POST anything to the initialized URL yet, but there's just a couple of lines needed, I guess. I will try to make it work. Also the QueuedHttpDispatcher sounds interesting.
What do you mean by the "POST standard" we could define? For dispatching via HTTP or for querying the worklist via REST/POST? Regards, --- balazs Ps.: it's always difficult to find out where to post a question. First I always try to find a "user" solution and in case it fails then we can go on develop something. This time it seems solving my problems will in fact involve some development. ;-) John Mettraux wrote: > Hi Balazs, > > > On 8/2/06, Balazs E. Pataki <[EMAIL PROTECTED]> wrote: >> Hi John, >> >> Hope you had a great time in Russia? :-) > > Never enough time to visit the Hermitage :-) > > >>> Isn't the fact of emitting a workitem towards your participants >>> already some kind of notification to your application ? Maybe the idea >>> would be to turn that the other way : your participant implementation >>> could receive the workitem and notify other parts of the application. >> Sure, I could implement a participant that works as a workitem consumer, >> but my problem is that I'm stick with PHP and Apache and I can't see how >> I could implement this consumer interface, because there doesn't seem to >> be an HTTP based dispatcher in the engine (I could find SocketDispatcher >> and SmtpDispatcher, and also the WSInvoker, but that doesn't dispatch >> the complete workitem). > > Now that you tell me, there's an HttpDispatcher in the works : > http://svn.sourceforge.net/viewvc/openwfe/trunk/openwfe/engine/src/openwfe/org/engine/impl/dispatch/HttpDispatcher.java?view=log > > But it's not yet finished and the accompanying HttpListener hasn't yet > surfaced. > > I plan on implementing a QueuedHttpDispatcher where workitems would be > queried per http GET by other applications (a small and stupid HTTP > worklist embedded within the engine). > > Would you like to test those artefacts ? > > (this reply would deserver being posted on openwfe-devel). > > >> That's why I thought that, becuase I'm happy with the funcionality of >> the worklist I don't want to replicate all its funcionality in PHP, >> rather I would dispatch workitems there, but would be great if I could >> inform my PHP application about the dispatch to the worklist. > > Maybe your PHP application could 'poll' the worklist from time to time. > > >> Although a side issue, but somehow relates to my previous problem. The >> only reason I seriously consider(ed) implementing some PHP based >> participant (worklist) that could work as a workitem listener/consumer >> is that the worklist REST interface doesn't support querying of >> workitems by workitem parameters (only getting all the headers and then >> selecting the appropriate workitems to download in - im my case - PHP >> time). > > We could define a POST standard for that. It could be useful for many people. > > >> However, I think I will use a SqlWorkItemStore in the worklist >> and query that directly from my PHP app and then download the complete >> workitems I need. My only concern with this approach is that the >> documentation states that "Warning :'swis' is currently not maintained >> actively anymore". But I hope it would work with the provided >> MysqlDataSource. Wouldn't it? :-) > > It could work out of the box, a few small adaptations to the later > OpenWFEs would certainly be required, but not much. > > > Best regards, > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ OpenWFE - Open source WorkFlow Engine OpenWFE-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openwfe-users
