Hi all OK for the version 1
About the code, I prefer to create a repository in my github account and push the code later to Stanbol branch. This way we keep separately the GSoC code from issue branching. What do you think? Regards On Mon, May 26, 2014 at 10:11 AM, Florent André <flor...@apache.org> wrote: > Antonio, > > About the version, Rupert can fix my words, but It's seems that 0.12 and > 1.0 have few differences and up-coming 1.0 release will not break this. > > So I thinks it's better so start on 1.0 and port it to 0.12 afterward if > needed. > > Side question : > As Antonio is commiter, do he commit his code directly on a branch or in a > side github repository ? > > ++ > > > On 23/05/2014 14:49, Antonio David Perez Morales wrote: > >> Hi Rupert and Florent >> >> Of course Florent, I will create the needed issues for the tasks. This >> week I have been studying in depth the code of the Cameltrial PoC, >> reading and playing a lot with Camel. >> >> Please find my response in lines. >> >> >> Such routes would have some restrictions: (a) >> >> start with a request, >> >> >> They not directly answer to a "direct request" but when something is >> send to the email address (or put in a directory), the full >> Enhancement Route is launched. >> >> >> Camel supports triggering a route based on an endpoint (like direct, >> http or whatever) or when some event occurs in other component, like a >> document added to an ActiveMQ queue, a mail sent to a server, etc. >> So we can support both, the request-triggered method and another >> combination (leveraging the power of Camel components). >> >> For the midterm, I had thought to improve the Florent's code to support >> configuring route endpoints, and the engines used in each route. This >> task would act like the current Enhancement Chains but using Camel >> framework. >> For the second part of the project (which has more time than the first >> one) we could add new things like apply real integration patterns inside >> routes to do parallel processing of engines, etc. >> >> >> (b) end with a response, >> >> Depending on you camel output, "end with a response" is not exactly >> true in an "classical resquest/reponse http thought"... >> >> I mean that the response of a "route" can be a mail sended or an rdf >> serialization write to an ftp... >> >> >> For the time being, we can not consider this feature, but we could add >> it later if necessary to support something more than the classic >> request/response flow. >> >> === 5) defining and implementing easy routing definition === >> >> In my first version of code, adding a new route require to >> build a bundle >> and add it to Stanbol. >> The structure, and the code of this bundle is pretty simple >> and allow to >> code you route with java DSL (with one I pretty like), but >> maybe lack a >> little bit of flexibility and user friendliness. >> >> >> Here, we could support several alternatives: >> - create bundles with classes extending RouteBuilder (to build route >> definitions and declared as Osgi component) to deploy new routes >> declared in Java DSL >> - deploy routes in XML format, putting a file in an specific directory >> (Camel Spring XML format) >> - deploy routes in XML format enabling a REST endpoint receiving XML >> route definitions. >> >> >> I would suggest to provide such a RESTful service as part of the >> the >> Felix Webconsole. This would also allow to provide a simple UI >> as tab >> of the Felix WebConsole (similar to the tab of the >> DataFileProvider). >> >> >> This option could be a good to have, but I should do some researches on >> how to extend Felix WebConsole, so I think this is not a priority right >> now. >> >> >> By the way, which version do you recommend me to use in order to >> implement the project, Stanbol 0.12 or 1.0 version? >> >> Best regards >> >> >> ------------------------------------------------------------------------ >> 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 Brook House, 229 Shepherds Bush >> Road, London W6 7AN. >> > -- ------------------------------ 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 Brook House, 229 Shepherds Bush Road, London W6 7AN.
