Hi, yes we discussed such chains a while ago and they are definitely on the roadmap. If I remember correctly, the idea was to have different chains at different URLs.
/engines/fastchain /engines/mytestchain ... something like that Best, - Fabian 2011/7/9 florent andré <[email protected]>: > Near this idea, I think that the need of multiple processing chains in > Stanbol will appear. > > As for example, when upload a document, (at least) two types of processing > chain could be useful : > > - The first one - fast - with just one or two "essentials" engines, provide > entities to the users in (near) "real time" > > - The second one - slower -with a lot of engines, provided a detailed > analysis, and computations that help for classification, summary, detailed > enhancements, etc... and are displayed to the user later or when reopen > document. > > As I know, for now, the only way to do that is to set up two different > Stanbol servers, with a different engine stack for each... > > An opportunity to define different processing chain is something in the > roadmap ? > > ++ > > > > > On 07/06/2011 11:54 PM, Ezequiel Foncubierta wrote: >> >> Hi, >> >> I'm not sure if this option is currently supported or there is a plan to >> do it. I think that would be interesting to enable an async option when you >> call the engines/ resource. If the system is overloaded, or some engines >> take a long time to process the content, it should be an option to run >> asynchronous transactions. Some integrations requires synchronous calls, >> because they want to tag contents in the same transactions. But, could be >> some others in which the synchronous calls are not a required feature. >> >> This proposal is because, almost the all the current integration uses >> synchronous calls. It means that, the content creation process is as >> following: >> >> 1. Create the content in the CMS >> 2. Send the content to the enhancer >> 3. Write the enhancer results >> 4. Relate the content with the extracted entities >> >> So, the CMS performance depends on the Apache Stanbol performance. An >> alternative, would be creating the content and run a background process to >> extract the enhancements (using different transactions). >> >> A first way to get it, is by sending a url parameter (e.g. >> referer=http://system/listener/service). If this parameter is present, then >> run the enhancements in a background thread and, once finished, then send >> the results to the specified url in the referer parameter. >> >> You know better than me the pros and cons of the current implementation, >> so... what do you think about the asynchronous calls? >> >> Thanks. Regards, >> >> -- >> Ezequiel Foncubierta >> This message should be regarded as confidential. If you have received this >> email in error please notify the sender and destroy it immediately. >> Statements of intent shall only become binding when confirmed in hard copy >> by an authorised signatory. >> >> Zaizi Ltd is registered in England and Wales with the registration number >> 6440931. The Registered Office is 203 Westbourne Studios, 242 Acklam Road, >> London W10 5JJ, UK. >> > -- Fabian
