Restlet Framework NG

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Restlet Framework NG

Jerome Louvel-3
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Gernot Pansy
Hi,

Thanks, for sharing your slides and the code. Looks very promising after a first quick look. Cleaned up a lot of modules which i never used and added the missing part (HTTP 2.0 & async/reactive) with netty. The way to go.

They only module missing for me is the oauth module. That was also the reason for me, to choose the restlet over any other solution. 
So what's the plan for additional modules. Will their be an addtional repo that restlet maintains or should that be completely and user control?

For dependency injection i have always used guice in my restlet projects (because it's the only option), but here i think dagger2 should be prefered (especially for android). But that's not easy to change, because is deeply integrated in restlet and will make porting the projects to v3 much more complex.

Hopefully, freemarker will now be only a optional dependency.

cheers,
gernot


2016-09-17 4:16 GMT+02:00 Jerome Louvel <[hidden email]>:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Jerome Louvel-3
In reply to this post by Jerome Louvel-3
Hi Xavier,

I agree for the performance aspect being important to enabling new use cases for the framework, including big data and microservices.

We need to make sure that we benchmark the new runtime and optimize under the hood (added this issue).

In the prototype code base, Netty is directly bound to the higher-level Restlet API's Request and Response classes, bypassing the adapter layer we have in v2 to support pluggable connectors.
That will also allow us to do optimizations and take the most out of Netty.

Thanks for the feedback!
Jerome


On Fri, Sep 16, 2016 at 11:39 PM, Xavier Mehaut <[hidden email]> wrote:
Hi Jerome
It looks nice and necessary (especially java8 for lambda fct, reactive streams, and http2). Simplifying the user experience and consequently the complexity under the  hood is mandatory, and also having greater performances through asynchronism is needed. It could open the gate to frameworks like kafka or spark streaming / flink.
Regards
Xavier  

Envoyé de mon iPhone

Le 17 sept. 2016 à 04:16, Jerome Louvel <[hidden email]> a écrit :

Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Jerome Louvel-3
In reply to this post by Gernot Pansy
Hi Gernot,

Thx for the feedback!

The list of extensions is a starting point to ensure we focus our efforts on a smaller code base. Supporting OAuth is very important for today's web APIs, so we definitely want to have an extension for it. Whether it is going to be based on the existing OAuth extension in V2 or whether we build a brand new one is up for discussion.

Totally agree for Dragger support for Android, I've added this RFE to add it in our radar (contributions welcome).
I think we need to keep supporting Guice as well so that porting to Dagger isn't mandatory.

For FreeMarker, this isn't mandatory dependency in V2 today, so you can already use alternative template libraries like Velocity, Thymeleaf, etc.
So there is really no plan to force usage of Apache Freemarker moving forward :)

Actually we upgraded support for Thymeleaf to v3 in the prototype and it will be interesting to see how their support for reactive templating with back pressure support will fit into the new Netty-based Restlet API processing layer. Hopefully, it will allow us to support long streaming representations based on templates, without blocking threads.

Best,
Jerome


On Sat, Sep 17, 2016 at 1:37 AM, Gernot Pansy <[hidden email]> wrote:
Hi,

Thanks, for sharing your slides and the code. Looks very promising after a first quick look. Cleaned up a lot of modules which i never used and added the missing part (HTTP 2.0 & async/reactive) with netty. The way to go.

They only module missing for me is the oauth module. That was also the reason for me, to choose the restlet over any other solution. 
So what's the plan for additional modules. Will their be an addtional repo that restlet maintains or should that be completely and user control?

For dependency injection i have always used guice in my restlet projects (because it's the only option), but here i think dagger2 should be prefered (especially for android). But that's not easy to change, because is deeply integrated in restlet and will make porting the projects to v3 much more complex.

Hopefully, freemarker will now be only a optional dependency.

cheers,
gernot


2016-09-17 4:16 GMT+02:00 Jerome Louvel <[hidden email]>:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Tim Peierls
I wrote a lengthy comment to that RFE.

On Sat, Sep 17, 2016 at 11:07 AM, Jerome Louvel <[hidden email]> wrote:
Hi Gernot,

Thx for the feedback!

The list of extensions is a starting point to ensure we focus our efforts on a smaller code base. Supporting OAuth is very important for today's web APIs, so we definitely want to have an extension for it. Whether it is going to be based on the existing OAuth extension in V2 or whether we build a brand new one is up for discussion.

Totally agree for Dragger support for Android, I've added this RFE to add it in our radar (contributions welcome).
I think we need to keep supporting Guice as well so that porting to Dagger isn't mandatory.

For FreeMarker, this isn't mandatory dependency in V2 today, so you can already use alternative template libraries like Velocity, Thymeleaf, etc.
So there is really no plan to force usage of Apache Freemarker moving forward :)

Actually we upgraded support for Thymeleaf to v3 in the prototype and it will be interesting to see how their support for reactive templating with back pressure support will fit into the new Netty-based Restlet API processing layer. Hopefully, it will allow us to support long streaming representations based on templates, without blocking threads.

Best,
Jerome


On Sat, Sep 17, 2016 at 1:37 AM, Gernot Pansy <[hidden email]> wrote:
Hi,

Thanks, for sharing your slides and the code. Looks very promising after a first quick look. Cleaned up a lot of modules which i never used and added the missing part (HTTP 2.0 & async/reactive) with netty. The way to go.

They only module missing for me is the oauth module. That was also the reason for me, to choose the restlet over any other solution. 
So what's the plan for additional modules. Will their be an addtional repo that restlet maintains or should that be completely and user control?

For dependency injection i have always used guice in my restlet projects (because it's the only option), but here i think dagger2 should be prefered (especially for android). But that's not easy to change, because is deeply integrated in restlet and will make porting the projects to v3 much more complex.

Hopefully, freemarker will now be only a optional dependency.

cheers,
gernot


2016-09-17 4:16 GMT+02:00 Jerome Louvel <[hidden email]>:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Tal Liron-2
In reply to this post by Jerome Louvel-3
Looks exciting!

My hope is that we will not go entirely into requiring annotations and IoC. I'm primarily a non-Java (Nashorn, Jython, JRuby, Clojure, etc.) consumer of Restlet, and it's crucial there that plain, straightforward Java classes and interfaces will continue working with Restlet. As long as annotations are optional, Restlet will continue being an excellent foundation for those use cases.

On Fri, Sep 16, 2016 at 9:16 PM, Jerome Louvel <[hidden email]> wrote:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Kristoffer Gronowski
In reply to this post by Tim Peierls
Hi!

If there is a big interest for OAuth2 I can try to help out and write it again if you want.
@Gernot, what part is more important, to write client side consumer, a protected resource or even your own OAuth/OID server.

I personally write all of the above and so far Restlet has not disappointed.

Have two things I would like to improve.
I have a wrapper over Client Resource that does message cleanup better. On occasions I have ended up with starvation.
Because there are unconsumed resources. There would be nicer to have a cleaner way to make sure exiting the handler everything is reclaimed. I'm more of a power user and if I suffer for sure other will too.

Handling files and servig Directories. I know REST is the focus but often you want to server some files too.
Even if I have done it tons of times it always consumes 90% of my effort. So it would not hurt to be improved.

Regards Kristoffer

On Sat, Sep 17, 2016 at 10:59 AM, Tim Peierls <[hidden email]> wrote:
I wrote a lengthy comment to that RFE.

On Sat, Sep 17, 2016 at 11:07 AM, Jerome Louvel <[hidden email]> wrote:
Hi Gernot,

Thx for the feedback!

The list of extensions is a starting point to ensure we focus our efforts on a smaller code base. Supporting OAuth is very important for today's web APIs, so we definitely want to have an extension for it. Whether it is going to be based on the existing OAuth extension in V2 or whether we build a brand new one is up for discussion.

Totally agree for Dragger support for Android, I've added this RFE to add it in our radar (contributions welcome).
I think we need to keep supporting Guice as well so that porting to Dagger isn't mandatory.

For FreeMarker, this isn't mandatory dependency in V2 today, so you can already use alternative template libraries like Velocity, Thymeleaf, etc.
So there is really no plan to force usage of Apache Freemarker moving forward :)

Actually we upgraded support for Thymeleaf to v3 in the prototype and it will be interesting to see how their support for reactive templating with back pressure support will fit into the new Netty-based Restlet API processing layer. Hopefully, it will allow us to support long streaming representations based on templates, without blocking threads.

Best,
Jerome


On Sat, Sep 17, 2016 at 1:37 AM, Gernot Pansy <[hidden email]> wrote:
Hi,

Thanks, for sharing your slides and the code. Looks very promising after a first quick look. Cleaned up a lot of modules which i never used and added the missing part (HTTP 2.0 & async/reactive) with netty. The way to go.

They only module missing for me is the oauth module. That was also the reason for me, to choose the restlet over any other solution. 
So what's the plan for additional modules. Will their be an addtional repo that restlet maintains or should that be completely and user control?

For dependency injection i have always used guice in my restlet projects (because it's the only option), but here i think dagger2 should be prefered (especially for android). But that's not easy to change, because is deeply integrated in restlet and will make porting the projects to v3 much more complex.

Hopefully, freemarker will now be only a optional dependency.

cheers,
gernot


2016-09-17 4:16 GMT+02:00 Jerome Louvel <[hidden email]>:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Gernot Pansy
@kristoffer we use the oauth2 server part in all of our restlet projects. your offer sound very cool ;-), but otherwise we will do it on our own and share it. 

cheers
gernot

2016-09-17 20:08 GMT+02:00 Kristoffer Gronowski <[hidden email]>:
Hi!

If there is a big interest for OAuth2 I can try to help out and write it again if you want.
@Gernot, what part is more important, to write client side consumer, a protected resource or even your own OAuth/OID server.

I personally write all of the above and so far Restlet has not disappointed.

Have two things I would like to improve.
I have a wrapper over Client Resource that does message cleanup better. On occasions I have ended up with starvation.
Because there are unconsumed resources. There would be nicer to have a cleaner way to make sure exiting the handler everything is reclaimed. I'm more of a power user and if I suffer for sure other will too.

Handling files and servig Directories. I know REST is the focus but often you want to server some files too.
Even if I have done it tons of times it always consumes 90% of my effort. So it would not hurt to be improved.

Regards Kristoffer

On Sat, Sep 17, 2016 at 10:59 AM, Tim Peierls <[hidden email]> wrote:
I wrote a lengthy comment to that RFE.

On Sat, Sep 17, 2016 at 11:07 AM, Jerome Louvel <[hidden email]> wrote:
Hi Gernot,

Thx for the feedback!

The list of extensions is a starting point to ensure we focus our efforts on a smaller code base. Supporting OAuth is very important for today's web APIs, so we definitely want to have an extension for it. Whether it is going to be based on the existing OAuth extension in V2 or whether we build a brand new one is up for discussion.

Totally agree for Dragger support for Android, I've added this RFE to add it in our radar (contributions welcome).
I think we need to keep supporting Guice as well so that porting to Dagger isn't mandatory.

For FreeMarker, this isn't mandatory dependency in V2 today, so you can already use alternative template libraries like Velocity, Thymeleaf, etc.
So there is really no plan to force usage of Apache Freemarker moving forward :)

Actually we upgraded support for Thymeleaf to v3 in the prototype and it will be interesting to see how their support for reactive templating with back pressure support will fit into the new Netty-based Restlet API processing layer. Hopefully, it will allow us to support long streaming representations based on templates, without blocking threads.

Best,
Jerome


On Sat, Sep 17, 2016 at 1:37 AM, Gernot Pansy <[hidden email]> wrote:
Hi,

Thanks, for sharing your slides and the code. Looks very promising after a first quick look. Cleaned up a lot of modules which i never used and added the missing part (HTTP 2.0 & async/reactive) with netty. The way to go.

They only module missing for me is the oauth module. That was also the reason for me, to choose the restlet over any other solution. 
So what's the plan for additional modules. Will their be an addtional repo that restlet maintains or should that be completely and user control?

For dependency injection i have always used guice in my restlet projects (because it's the only option), but here i think dagger2 should be prefered (especially for android). But that's not easy to change, because is deeply integrated in restlet and will make porting the projects to v3 much more complex.

Hopefully, freemarker will now be only a optional dependency.

cheers,
gernot


2016-09-17 4:16 GMT+02:00 Jerome Louvel <[hidden email]>:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Jerome Louvel-3
In reply to this post by Tal Liron-2
Tal,

No worry, the intention is to keep the existing class based Restlet API capabilities and continue improving annotation/interface capabilities on top of it (optionally).

Cheers!
Jerome


On Sat, Sep 17, 2016 at 11:04 AM, Tal Liron <[hidden email]> wrote:
Looks exciting!

My hope is that we will not go entirely into requiring annotations and IoC. I'm primarily a non-Java (Nashorn, Jython, JRuby, Clojure, etc.) consumer of Restlet, and it's crucial there that plain, straightforward Java classes and interfaces will continue working with Restlet. As long as annotations are optional, Restlet will continue being an excellent foundation for those use cases.

On Fri, Sep 16, 2016 at 9:16 PM, Jerome Louvel <[hidden email]> wrote:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Jerome Louvel-3
Thanks a lot guys for all your feed-back, that's very motivating!
I will reply to each of you this week.

Jérôme


On Sat, Sep 17, 2016 at 12:01 PM, Jerome Louvel <[hidden email]> wrote:
Tal,

No worry, the intention is to keep the existing class based Restlet API capabilities and continue improving annotation/interface capabilities on top of it (optionally).

Cheers!
Jerome


On Sat, Sep 17, 2016 at 11:04 AM, Tal Liron <[hidden email]> wrote:
Looks exciting!

My hope is that we will not go entirely into requiring annotations and IoC. I'm primarily a non-Java (Nashorn, Jython, JRuby, Clojure, etc.) consumer of Restlet, and it's crucial there that plain, straightforward Java classes and interfaces will continue working with Restlet. As long as annotations are optional, Restlet will continue being an excellent foundation for those use cases.

On Fri, Sep 16, 2016 at 9:16 PM, Jerome Louvel <[hidden email]> wrote:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].



--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Jerome Louvel-3
In reply to this post by Kristoffer Gronowski
Kristoffer,

That would be great if you could help with a new OAuth/OID extension.
I've entered this RFE in the new repo to keep track of this and added references to related libraries like Scribe and Apache Oltu.

Happy to improve ClientResource as well.
Can you give more details about how the additional message cleanup you need to do in your wrapper?

Regarding serving static files/directories, I agree we should keep this existing capability.
How would you like to see it improved? Is it about configuration and debugging mostly?

Best regards,
Jerome



On Sat, Sep 17, 2016 at 11:08 AM, Kristoffer Gronowski <[hidden email]> wrote:
Hi!

If there is a big interest for OAuth2 I can try to help out and write it again if you want.
@Gernot, what part is more important, to write client side consumer, a protected resource or even your own OAuth/OID server.

I personally write all of the above and so far Restlet has not disappointed.

Have two things I would like to improve.
I have a wrapper over Client Resource that does message cleanup better. On occasions I have ended up with starvation.
Because there are unconsumed resources. There would be nicer to have a cleaner way to make sure exiting the handler everything is reclaimed. I'm more of a power user and if I suffer for sure other will too.

Handling files and servig Directories. I know REST is the focus but often you want to server some files too.
Even if I have done it tons of times it always consumes 90% of my effort. So it would not hurt to be improved.

Regards Kristoffer

On Sat, Sep 17, 2016 at 10:59 AM, Tim Peierls <[hidden email]> wrote:
I wrote a lengthy comment to that RFE.

On Sat, Sep 17, 2016 at 11:07 AM, Jerome Louvel <[hidden email]> wrote:
Hi Gernot,

Thx for the feedback!

The list of extensions is a starting point to ensure we focus our efforts on a smaller code base. Supporting OAuth is very important for today's web APIs, so we definitely want to have an extension for it. Whether it is going to be based on the existing OAuth extension in V2 or whether we build a brand new one is up for discussion.

Totally agree for Dragger support for Android, I've added this RFE to add it in our radar (contributions welcome).
I think we need to keep supporting Guice as well so that porting to Dagger isn't mandatory.

For FreeMarker, this isn't mandatory dependency in V2 today, so you can already use alternative template libraries like Velocity, Thymeleaf, etc.
So there is really no plan to force usage of Apache Freemarker moving forward :)

Actually we upgraded support for Thymeleaf to v3 in the prototype and it will be interesting to see how their support for reactive templating with back pressure support will fit into the new Netty-based Restlet API processing layer. Hopefully, it will allow us to support long streaming representations based on templates, without blocking threads.

Best,
Jerome


On Sat, Sep 17, 2016 at 1:37 AM, Gernot Pansy <[hidden email]> wrote:
Hi,

Thanks, for sharing your slides and the code. Looks very promising after a first quick look. Cleaned up a lot of modules which i never used and added the missing part (HTTP 2.0 & async/reactive) with netty. The way to go.

They only module missing for me is the oauth module. That was also the reason for me, to choose the restlet over any other solution. 
So what's the plan for additional modules. Will their be an addtional repo that restlet maintains or should that be completely and user control?

For dependency injection i have always used guice in my restlet projects (because it's the only option), but here i think dagger2 should be prefered (especially for android). But that's not easy to change, because is deeply integrated in restlet and will make porting the projects to v3 much more complex.

Hopefully, freemarker will now be only a optional dependency.

cheers,
gernot


2016-09-17 4:16 GMT+02:00 Jerome Louvel <[hidden email]>:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Restlet Framework NG

Jerome Louvel-3
In reply to this post by Tim Peierls
Awesome Tim! I've continued the discussion in the GitHub RFE directly.

Jerome

On Sat, Sep 17, 2016 at 10:59 AM, Tim Peierls <[hidden email]> wrote:
I wrote a lengthy comment to that RFE.

On Sat, Sep 17, 2016 at 11:07 AM, Jerome Louvel <[hidden email]> wrote:
Hi Gernot,

Thx for the feedback!

The list of extensions is a starting point to ensure we focus our efforts on a smaller code base. Supporting OAuth is very important for today's web APIs, so we definitely want to have an extension for it. Whether it is going to be based on the existing OAuth extension in V2 or whether we build a brand new one is up for discussion.

Totally agree for Dragger support for Android, I've added this RFE to add it in our radar (contributions welcome).
I think we need to keep supporting Guice as well so that porting to Dagger isn't mandatory.

For FreeMarker, this isn't mandatory dependency in V2 today, so you can already use alternative template libraries like Velocity, Thymeleaf, etc.
So there is really no plan to force usage of Apache Freemarker moving forward :)

Actually we upgraded support for Thymeleaf to v3 in the prototype and it will be interesting to see how their support for reactive templating with back pressure support will fit into the new Netty-based Restlet API processing layer. Hopefully, it will allow us to support long streaming representations based on templates, without blocking threads.

Best,
Jerome


On Sat, Sep 17, 2016 at 1:37 AM, Gernot Pansy <[hidden email]> wrote:
Hi,

Thanks, for sharing your slides and the code. Looks very promising after a first quick look. Cleaned up a lot of modules which i never used and added the missing part (HTTP 2.0 & async/reactive) with netty. The way to go.

They only module missing for me is the oauth module. That was also the reason for me, to choose the restlet over any other solution. 
So what's the plan for additional modules. Will their be an addtional repo that restlet maintains or should that be completely and user control?

For dependency injection i have always used guice in my restlet projects (because it's the only option), but here i think dagger2 should be prefered (especially for android). But that's not easy to change, because is deeply integrated in restlet and will make porting the projects to v3 much more complex.

Hopefully, freemarker will now be only a optional dependency.

cheers,
gernot


2016-09-17 4:16 GMT+02:00 Jerome Louvel <[hidden email]>:
Hi all,

Today at the REST Fest event, I had the opportunity to present a project and some initial prototyping efforts to upgrade the Restlet Framework:

I'm looking forward for any early feedback!

--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].


--
You received this message because you are subscribed to the Google Groups "Restlet Framework (Discuss)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
Loading...