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/

Reply via email to