Hi all IMHO all GSoC stuff should use the trunk (1.0.0-SNAPSHOT) as starting point for the branches.
@Antonio, Florent: I do not think that we will back port the Camel integration to 0.12.* best Rupert On Mon, May 26, 2014 at 10:18 AM, Antonio David Perez Morales <ape...@zaizi.com> wrote: > 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. -- | Rupert Westenthaler rupert.westentha...@gmail.com | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen | REDLINK.CO .......................................................................... | http://redlink.co/