You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2007/05/23 15:06:27 UTC
Work items for the next release?
Now that the 0.90 release is almost out i was wondering about what things to
work on next and came up a list of possibilities. Its not meant as any sort
of complete list, just things that came to mind skimming over SVN, and it
leaves out things others have been talking about as it was more for what I
could be doing. I wondered if any one had any comments on which of these
sounded useful, or not so useful, which would be good to get done soon or in
the next release, of if there were other things not on this list which might
be better to get done first? Anyone want to do or help with any of these?
Ones that interest me for the next release which I've already started
looking at are some of the Script items and the JMS and AMQP bindings.
...ant
Axis2
- work without pre-existing wsdl doc
- support attachments
- support accessing/setting SOAP headers
- WS-RM and WS-Security
- support WSA EPR in <binding.ws>
- async
- conversational
- Fix open jira's about ?wsdl and endpoint url
- support setting some optional stuff like Axis2 handlers, chunking, soap
version etc
Sort out our WSDL tooling story
- get SDO integrated into Axis2?
IDLs
- support WSDL 2.0
Runtime
- async
- conversational
Script
- optional .componentType sidefile
- 'any' style proxy for languages that support this
- support XML style as appropriate - E4X, ReXML etc
- groovy with annotations
WebApp
- conversational and sessions
- fix static servletHost
- deep integration
Binding-JMS
- get going agian
- support async
- support 1.0 spec
Binding-ampq
- create a new amqp binding
- support async
Binding-hessian
- get going agian
binding-ajax
- fix issue with reference needing same thread as a service
binding-jsonrpc
- fix current issues - servlet non-transient etc
- can we get comet/reverse ajax style references working?
implementation-bpel
- get old Ode code going again and finish
EJB extension
- get JIRA code integrated and working in the new runtime
policy
- get at least one working (security/rm in Axis2?)
spring container
- get it going again
Mediation
- as a minimum some sort of Mediator.mediate(Message) interface services can
use?
Distributions
- don't want to always distribute *everything*
- maybe distributions targeting each runtime and you can +/- extensions when
you build the distro?
Re: An Atom+RSS Feed binding, was: Work items for the next release?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> Sebastien. Nice one. I used the service binding and it looks good.
>
> Would also like to use the reference binding (will help remove some cruft
> from the other feed aggregator sample). For me the thing I would like
> to add
> is a parameter to the "get()" method that allows me to override the
> URL set
> in the SCDL file. There is a fine line though between extending the
> binding
> and providing an library component. I don't know where the line is b.t.w
>
> +1 for including in head.
>
> I think this type of composition is really powerful for add-hoc data
> aggregation. I'm sure other bindings could be created in the same
> vein, e.g.
> NNTP, simple CRUD etc. Anybody fancy having a go?
>
> Regards
>
> Simon
>
The feed binding and the feed aggregator sample are now in trunk and
included in the main build.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: An Atom+RSS Feed binding, was: Work items for the next release?
Posted by Simon Laws <si...@googlemail.com>.
Sebastien. Nice one. I used the service binding and it looks good.
Would also like to use the reference binding (will help remove some cruft
from the other feed aggregator sample). For me the thing I would like to add
is a parameter to the "get()" method that allows me to override the URL set
in the SCDL file. There is a fine line though between extending the binding
and providing an library component. I don't know where the line is b.t.w
+1 for including in head.
I think this type of composition is really powerful for add-hoc data
aggregation. I'm sure other bindings could be created in the same vein, e.g.
NNTP, simple CRUD etc. Anybody fancy having a go?
Regards
Simon
Re: An Atom+RSS Feed binding, was: Work items for the next release?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jean-Sebastien Delfino wrote:
> Simon Laws wrote:
>> Ok, sounds good. I started to look at ROME but go distracted by
>> something
>> else and I haven't looked at Abdera. So if you have a binding on the
>> way
>> that would be really good. Am back looking at bringing up the aggregator
>> sample so I'll leave the implementation of the feed readers a little
>> hazy in
>> anticipation of using your stuff.
>>
>> Thanks
>>
>> Simon
>>
>
> Simon,
>
> Under revision r543070 I have committed a strawman implementation of a
> Feed binding that uses Rome to handle both Atom and RSS feeds.
>
> The binding code is there:
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/modules/binding-feed/
>
> There's a sample there:
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/samples/feed-aggregator/
>
>
> The sample shows how to implement a simple SCA component that gets
> Atom and RSS feeds using the Feed binding, and aggregates them into a
> new feed, available in both RSS and Atom forms. Both the binding and
> sample are very simple, there's not much code at all, but I think
> it'll help build the bigger AlertAggregator sample.
>
> To try it out, run the feed.SampleServer class in
> samples/feed-aggregator, it'll start the FeedAggregator SCA composite
> with an embedded Tomcat and will display the URLs that you can browse
> to get the aggregated feeds.
>
> Let me know if you find it useful, any suggestions to improve it are
> welcome. If people review it and find it useful I'd like to contribute
> it to trunk in the next few days.
>
I'd like to move this binding plus the small feed-aggregator sample
component to the trunk.
It would be great if some people could take a look and have any
suggestions to improve it or any ideas for components that could
leverage it, in addition to the aggregator component.
If there's no objection, I'm planning to add a few test cases to it and
move it over sometime this weekend.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: An Atom+RSS Feed binding, was: Work items for the next release?
Posted by Simon Laws <si...@googlemail.com>.
Oh yes. I think we can simplify the demo by using the reference side also.
I occured to me that we have both started using feed-aggregator for the
samples we are wokring on. Go ahead and use that for the simple version.
I'll change the sample I've been working back to alert-aggregator or we are
just going to get confused:-) Not sure why I changed it from alert
aggregator in the first place. I don't have a good excuse.
Simon
Re: An Atom+RSS Feed binding, was: Work items for the next release?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> I've just committed a strawman port to Java of the Feed Aggregator
> application into my sandbox so that It now runs on the Java runtime.
>
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/feed-aggregator/
>
>
> It depends on Sebastien's feed binding so you will need that as well
>
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/modules/binding-feed/
>
>
> So if you run mvn in feed-aggregator it should build you a war that
> you can
> deploy to tomcat and you are set (I get an exception when deploying
> that I
> haven't looked at yet but doesn't stop it running)
>
> I've reused the application look and feel so it should look familiar
> but a
> lot of the code is new, for example, it's in Java now as opposed to
> Python.
> Here's a picture
>
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/feed-aggregator/aggregator.png
>
>
> Basically is an example of using the binding infrastructure to support
> different channels. There are three in this case.
>
> 1/ A HTTP based feed that can be read from any RSS/Atom feed reader. The
> server comes set up to read BBC news and Engadget so you can just
> point you
> feed reader at
>
> http://localhost:8080/sample-feed-aggregator/services/AlertsFeedServiceRSS
>
>
> And you should get something. This provides the feed using Sebastine's
> binding.feed service binding.
>
> 2/ A Web 2.0 style where you can manage the feed list. Go to
>
> localhost://8080/samples-feed-aggregator/
>
> This does all its work by talking JSONRPC to the same services used
> behind
> the scenes in 1/
>
> 3/ A rest style app supported by a PHP SCA display component. This is a
> little more complex to set up. You need this project and you need PHP
> installed with the latest version of the PHP SCA_SDO extension.
>
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/httpserver.php/
>
>
> This app could do with being a little less Web2.0 and more like a
> standard
> PHP app but I already had most of this so I went with what I had for this
> exercise. In this case it talks to the same services using web services.
>
> So, there were a couple of issues along the way:
>
> - The JSONRPC biding fails when transforming my SDOs to JSON (Its OK
> going
> JSON->SDO) I had to create my own POJOs and do manual transformations.
> - JSON->SDO can't handle properties called "Type"
> - We could do with a JSONRPC client.
> - The runtime go confused when I tried to create a service with two
> interfaces.
> - And of course I get that exception when starting Tomcat
>
> There are lots of things we could do
>
> - include the binding.feed for retrieving the RSS/Atom feed data as
> well as
> - Combine AlertFeedService and AlertService
> - Remove all the manual SDO stuff
> - Generally have a tidy up to make such we are demonstrating good
> practice.
> Looks messy with the work rounds in and the error handling needs
> sorting out
> - Make the Web2.0 client more obviously Web2.0 client by cutting down on
> server interactions
> - Make the PHP rest client less Web2.0 and decide what to do with this
> client (would be nice to have a rest rpc binding in Java :-)
> - Add back a Python component
>
> Anyhow I would like to get this in HEAD alongside the other demos. So
> take a
> look and see what you think
>
> Simon
>
This all sounds pretty good to me, I'll take a look at the demo app.
Funny :) I just sent an email asking people to review the feed binding
and suggest improvements and saying I wanted to move it to trunk over
the weekend... then I press Get mail and it looks like you've done much
more than review it and are already using it in the demo :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: An Atom+RSS Feed binding, was: Work items for the next release?
Posted by Simon Laws <si...@googlemail.com>.
I've just committed a strawman port to Java of the Feed Aggregator
application into my sandbox so that It now runs on the Java runtime.
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/feed-aggregator/
It depends on Sebastien's feed binding so you will need that as well
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/modules/binding-feed/
So if you run mvn in feed-aggregator it should build you a war that you can
deploy to tomcat and you are set (I get an exception when deploying that I
haven't looked at yet but doesn't stop it running)
I've reused the application look and feel so it should look familiar but a
lot of the code is new, for example, it's in Java now as opposed to Python.
Here's a picture
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/feed-aggregator/aggregator.png
Basically is an example of using the binding infrastructure to support
different channels. There are three in this case.
1/ A HTTP based feed that can be read from any RSS/Atom feed reader. The
server comes set up to read BBC news and Engadget so you can just point you
feed reader at
http://localhost:8080/sample-feed-aggregator/services/AlertsFeedServiceRSS
And you should get something. This provides the feed using Sebastine's
binding.feed service binding.
2/ A Web 2.0 style where you can manage the feed list. Go to
localhost://8080/samples-feed-aggregator/
This does all its work by talking JSONRPC to the same services used behind
the scenes in 1/
3/ A rest style app supported by a PHP SCA display component. This is a
little more complex to set up. You need this project and you need PHP
installed with the latest version of the PHP SCA_SDO extension.
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/httpserver.php/
This app could do with being a little less Web2.0 and more like a standard
PHP app but I already had most of this so I went with what I had for this
exercise. In this case it talks to the same services using web services.
So, there were a couple of issues along the way:
- The JSONRPC biding fails when transforming my SDOs to JSON (Its OK going
JSON->SDO) I had to create my own POJOs and do manual transformations.
- JSON->SDO can't handle properties called "Type"
- We could do with a JSONRPC client.
- The runtime go confused when I tried to create a service with two
interfaces.
- And of course I get that exception when starting Tomcat
There are lots of things we could do
- include the binding.feed for retrieving the RSS/Atom feed data as well as
- Combine AlertFeedService and AlertService
- Remove all the manual SDO stuff
- Generally have a tidy up to make such we are demonstrating good practice.
Looks messy with the work rounds in and the error handling needs sorting out
- Make the Web2.0 client more obviously Web2.0 client by cutting down on
server interactions
- Make the PHP rest client less Web2.0 and decide what to do with this
client (would be nice to have a rest rpc binding in Java :-)
- Add back a Python component
Anyhow I would like to get this in HEAD alongside the other demos. So take a
look and see what you think
Simon
Re: An Atom+RSS Feed binding, was: Work items for the next release?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> Ok, sounds good. I started to look at ROME but go distracted by something
> else and I haven't looked at Abdera. So if you have a binding on the way
> that would be really good. Am back looking at bringing up the aggregator
> sample so I'll leave the implementation of the feed readers a little
> hazy in
> anticipation of using your stuff.
>
> Thanks
>
> Simon
>
Simon,
Under revision r543070 I have committed a strawman implementation of a
Feed binding that uses Rome to handle both Atom and RSS feeds.
The binding code is there:
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/modules/binding-feed/
There's a sample there:
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/sebastien/java/sca/samples/feed-aggregator/
The sample shows how to implement a simple SCA component that gets Atom
and RSS feeds using the Feed binding, and aggregates them into a new
feed, available in both RSS and Atom forms. Both the binding and sample
are very simple, there's not much code at all, but I think it'll help
build the bigger AlertAggregator sample.
To try it out, run the feed.SampleServer class in
samples/feed-aggregator, it'll start the FeedAggregator SCA composite
with an embedded Tomcat and will display the URLs that you can browse to
get the aggregated feeds.
Let me know if you find it useful, any suggestions to improve it are
welcome. If people review it and find it useful I'd like to contribute
it to trunk in the next few days.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: An Atom+RSS Feed binding, was: Work items for the next release?
Posted by Simon Laws <si...@googlemail.com>.
Ok, sounds good. I started to look at ROME but go distracted by something
else and I haven't looked at Abdera. So if you have a binding on the way
that would be really good. Am back looking at bringing up the aggregator
sample so I'll leave the implementation of the feed readers a little hazy in
anticipation of using your stuff.
Thanks
Simon
An Atom+RSS Feed binding, was: Work items for the next release?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Simon Laws wrote:
>
> Demos
> Port feed aggregator over from Native SCA - has implications for
> scriting
> so I can help out there a bit.
>
>
I've started to put together a binding.feed extension. I'm currently
using Apache Abdera for Atom feeds, and have just started to look at the
ROME library for its RSS support.
It looks like it'll take just a few lines of code to implement a binding
like:
<reference name="aFeed">
<binding.feed uri="http://uri of the feed"/>
</reference>
Such a binding should help us easily implement applications similar to
the Tuscany Native SCA aggregator app on the Java runtime, while
shielding the SCA component implementation from the details of getting
and parsing the Atom or RSS feed.
I'll put that code in my sandbox later this week for people to take a look.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Work items for the next release?
Posted by Simon Laws <si...@googlemail.com>.
Ant
Wow, thats what I call a list. I can add a couple of things to the list that
I want to work on for the next release.
Runtime
Distributed domains (simple version of anyhow)
Demos
Port feed aggregator over from Native SCA - has implications for scriting
so I can help out there a bit.
So from this there are bound to be some runtime implementation additions
and I can support a bit of effort on the scripting side of things.
Other than that I see this as a breadth vs depth question. I.e. Do we make
what we have 100% or do we add new features. Certainly there needs to be a
bit of both but as we are not at 1.0 yet, It would be good to get more
breadth first to really shake down the runtime with the widest possible set
of features and then consolidate into 1.0. Just my opinion.
On this basis I would also like to add CXF integration to the list as I
discussed it at ApacheCon.
I have also seen other things mentioned on the list recently
Deeper integration with Geronimo (is this what you mean by WebApp - deep
integration?)
host/implementation.osgi?
implementation.xslt (some support in scripting now - do we need more)
Not sure what timescales for last points are of course, and I'm not
suggesting all this for the next release, but they have at least been raised
as interesting on the list.
So what do we do with out wish list? How about we Raise all of these as
feature requests in JIRA and put a query up on the web site for retrieving
them? We could even use the voting feature to indicate who is interested in
what?
Simon