Hi, Nice, thats a good idea. But anyway, if you need to process large files, an asynchronous option would be nice to avoid having connections waiting for a response. I think that both, configurable chains and asynchronous calls, ought to be implemented.
Regards, On 9 Jul 2011, at 12:05, Fabian Christ wrote: > 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 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.
