Hi,
With my spiffy new Release Manager hat on, I've put up everything
we've listed in this thread at
http://wiki.apache.org/ws/Tuscany/TuscanyCpp/Tasks - we now need to
decide what's [IN] or [OUT] for the release.
My comments inline below.
On 9/27/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Hi,
I added some comments inline, and my wish list at the bottom...
Andrew Borley wrote:
> A few things:
>
> - Python extension - could re-jig the core to allow Python components
> to not require a .componentType side file. Not necessary, but nice to
> have.
+1, it will make a difference in terms of usability.
We may also want to implement a way to pass structured data to Python
scripts in addition to simple types (using Python ElementTrees for example).
> - PHP extension - if we want to include this we need to add reference
> & property support to components and a client API (a locateService
> method)
+1, it would be great to bring the PHP extension to the same level of
function as the Ruby and Python extensions.
A side note: In addition to the injection of properties and references
into components, we currently provide a locateService method to clients.
This has been implemented for Ruby and Python, and we could very well
follow the same pattern for PHP, but I'm wondering if we could simplify
even more and just bind a global variable (some form of global variable
"injection") to the services available in the current composite instead
of forcing the client to call a locateService function or method. Any
thoughts on this?
Not sure if I understand this one - do you mean that for the component
"CalculatorComponent" which has a service named "CalculatorService",
rather than having a script that looks something like:
import SCA
calc = SCA.locateService("CalculatorComponent/CalculatorService")
result = calc.add( 12, 34 )
Your script would look like:
import SCA
result = SCA.CalculatorComponent.CalculatorService.add( 12, 34 )
?? Am I on the right track here?
> - Samples
> - do we include BigBank?
+1 to include BigBank, and maybe model the Web client part as an SCA
composite as well (in PHP if the PHP extension is ready).
> SupplyChain?
+1, how about using SupplyChain to illustrate the integration of
composites developed in multiple languages, C++, Ruby or PHP and Java
for example (or maybe we can use BigBank instead for that).
> - Tests
> - Do we want an equivalent of the sdotest app for SCA?
>
+1, more and more tests, integrated in the build system so people can
just test with a "make check".
> Andy
>
>
> On 9/25/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>> There have been significant changes since our last C++ release so I
>> think we
>> should plan for an M2 release in the next couple of weeks. We have
>> updated
>> to the latest assembly model, built a basic extension mechanism and
>> now have
>> extensions for Ruby, Python, PHP. Functionally this seems like good
>> content
>> for a new milestone but there will still be significant work items to
>> complete before we can cut a release.
>>
>> Let's use this thread to note the items to be completed and get
>> volunteers
>> to do the work. So for starters:
>>
>>
>> - Persuade someone to volunteer as Release Manager
We can check this one, Thanks Andy for volunteering :)
>> - Update Licence text in source files to the new Apache wording
>> (Pete)
>> - Update release build scripts for linux and windows
>> - Documentation
>> - Developer build instructions
>> - New language extensions
>> - Release notes
>> - Samples
>> - new samples for Ruby/Python??
>>
+1 to all of these!
I have a question on the samples, I'm not sure what to think about it.
Do people prefer to see the same sample implemented in multiple
languages? or different samples per language because they will fit
better with the particular language or will relate better to some well
known samples in that particular language space? I had initially started
with the same sample but I'm wondering if it's the right approach... Any
good ideas?
I think it's good to be able to compare how the same functionality is
produced on different languages, so I prefer the same sample in
multiple languages. I also think, if there are well known samples in a
particular language we should probably add the Tuscany take on those
as well. So +1 to both options!
Other items from my wish list added at the bottom...
>> Let's discuss the work items here and create a wiki page with a
>> checklist.
>>
>> Cheers,
>>
>> --
>> Pete
>>
>>
>
Here are a few more items I care about:
- Good scripting support (Ruby, Python, PHP) to lower the bar for people
who want to write and integrate useful SCA components in a few lines of
script.
This one's a bit ephemeral - aside from the removing the neccessity
for .componentType files where they aren't needed and your idea about
globally injecting the services above, do you have any other
particular ideas?
- REST support. We have the beginning of a REST support with Axis2C (on
the server side only now). I was thinking that we could complete this or
come up with an even lighter implementation directly as an Apache httpd
module.
Does the Axis2C REST support still work with the new Tuscany
dispatcher module? I couldn't work out how to get it going.
+1 for binding.rest reference support - did the discussions on how
this should be done boil down into something we can implement?
Would it be possible to have binding.rest service support based on the
Axis2C stuff? Would it just wrapper the binding.ws service code?
I also like the idea of an Apache module to provide the binding.rest
service support. Do you think it would be a lot of work?
- Speaking of Apache httpd, docs describing how to Tuscany / httpd + the
Axis2C axis2_mod. The Axis2c mini HTTP server is nice but we should make
sure that we can run with the real thing :)
+1
- Easy packaging and deployment. Maybe simplify and open our
tuscany-root folder structure to allow people to choose the structure
that best fits their environment.
At the moment I think the only requirement we have is that the root
must have packages and configuration subdirectories - do you propose
removing this requirement?
- Support for an identified level of the SCA assembly, binding and C&I
specs - 0.96? with a doc listing the limitations.
+1. I think 0.96 would the one to go for as this is what Java M2 will
be based on (I think). There may be some quite big limitations though
- do we have the effort available to implement the entirety of
property support (which requires xpath engines, etc) for example?
- One more scripting language, Javascript using Mozilla Spider-monkey?
Do we need this for this release? Javascript is pretty well supported
in the Java runtime right now.
- A small footprint with build options allowing people to build just
what they need (we've already started to some of these options to our
build).
+1
- A sample showing how to turn existing C and/or C++ code into an SCA
component.
+1 We should take some code that lots of people will know or already
use for this. Perhaps some OS function? Any ideas? Also, we'd need
useful docs to go with it.
- Real life samples, talking to Google, Yahoo and Amazon Web Services
for example.
+1 BigBank already goes out to a real stockquote service, but
something simple that looks up a book on Amazon (anyone written an SCA
book recently?!) would be cool and more obvious than BigBank
- A single helloworld sample?
Is this just to have a tick in the Helloworld box? IMO Calculator is
simple enough for newbies to understand.
- Platforms: Linux, Windows (VC++ express? VC6, or VC7?), and Mac OS-X.
+1 If we can get the bug that's stopping us on VC++ express I'd say we
just have that on Windows. I don't have access to any Mac OS-X
machines so we'll need someone to build the candidates & test on Mac -
any volunteers?
- Dependencies: Axis2C 0.94 if it's out soon. Stdcxx as a build option.
+1 So the list of downloadable packages wil be:
SDO Linux binary
SDO Linux binary with stdcxx
SDO Linux source
SDO Windows binary
SDO Windows binary with stdcxx
SDO Windows source
SDO Mac OS-X binary
SDO Mac OS-X binary with stdcxx?
SDO Mac OS-X source
SCA Linux binary
SCA Linux source
SCA Windows binary
SCA Windows source
SCA Mac OS-X binary
SCA Mac OS-X source
Phew! Does that look right?
- Finally docs, docs, docs :) The docs Pete listed above plus short user
how-to kind of docs to help people set up their environment, install or
build our runtime, write and run their first SCA app.
- A few short design docs describing the key aspects of our design (e.g.
our extensibility story) for people who want to understand how the
runtime works and contribute to it.
+1 for lots of doc :).
I'd better stop writing now, that's already a lot :). We probably cannot
do everything in this list, but as I said at the beginning, it's just a
wish list :)
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
