On 4/20/07, haleh mahbod <[EMAIL PROTECTED]> wrote:
Thanks for your comments. I haven't gone through all the details and will
do
that tomorrow. However, this caught my eye and wanted to better
understand
your comment.
>> Java SCA
>> - Architecture Guide
- still pointing to the old one
What do you mean by "still pointing to the old one". If you follow the
link
you should see this page
http://cwiki.apache.org/TUSCANY/java-sca-architecture-overview.html
I agree that the content should be updated, but want to make sure you are
seeing this page.
>> - DeveloperGuide
- I still think there should be a developer guide as it fits well
under
What is a developer guide and how is the content different than what would
go into the 'get involved' page under development section?
Here is what I was thinking (perhaps it is not right):
User Guide would hold things like:
- Installation/setup information
- user type documentation (SCA concepts and examples, etc)
- How to develop a simple SCA application followed with more
advanced
topics
GetInvolved link would point to information that anyone wanting to
contribute to SCA Java would need to know about, for example, code
structure, hints on development, etc.
Haleh
On 4/19/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 4/19/07, ant elder <[EMAIL PROTECTED]> wrote:
> >
> > On 4/19/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >
> > > On 4/19/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On 4/19/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > >
> > > > <snip/>
> > > >
> > > > - I like the list of modules I think we should go with the
> module
> > > name
> > > > > from the code and link to a separate
> > > > > page for each one. (take a look I've made an example). We
> can
> > > then
> > > > > use
> > > > > URLs such as
> > > > >
> http://cwiki.apache.org/confluence/display/TUSCANY/binding-wsto
> > > > > refer
> > > > > directly to the module description(*)
> > > >
> > > >
> > > > I like the one wiki page with the module name per module and as
> well,
> > > but
> > > > do we really want all of those listed on the "Java SCA Subproject
> > page"?
> > > > That page seems more user oriented giving an overview of Java SCA
> > > > capabilities, where as all the individual modules are a really
deep
> > > > implementation detail. For example how about on the "Java SCA
> > > Subproject"
> > > > page say Tuscany has a web service binding and links to a "web
> > service"
> > > > page
> > > > which talks about the WS capabilities and its that "web service"
> page
> > > > where
> > > > the list of WS related modules could go: binding-ws,
binding-ws-xml,
> > > > binding-ws-axis2, binding-ws-cxf, interface-wsdl,
> interface-wsdl-xml,
> > > > interface-wsdl-runtime etc. Similar thing for all the other
binding,
> > > > implementation, databinding, runtime etc.
> > > >
> > > > ...ant
> > > >
> > > I agree that this list doesn't need to go on this page but it would
be
> > > good
> > > to have a straight list somewhere so it's easy to get the low down
on
> a
> > > module. Perhaps in the develper guide as I had hoped that these
module
> > > pages
> > > will include design information. I would expect the user docs for
the
> > > modules, i.e. what to put in the SCDL to make them work, to go in
the
> > User
> > > Guide section. This could have a more user friendly index
> as suggested
> >
> >
> > A complete list does sound useful. How about the developer guide links
> to
> > something like an architecture page which has a diagram of the
runtime,
> a
> > bit of a description about it, and the complete list of modules? Eg,
> > Similar
> > to [1] but the other way up and more text explaining it.
> >
> > ...ant
> >
> > [1]
> >
> >
>
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Modulization+Design+Discussions
> >
> I thinks that's spot on. Didn't know the page had been extended to
include
> the module list. Lets link it into the architecture page (when we decide
> which architecture page we are having ;-). We can use module links from
> this
> page to record module design information. Module user information would
be
> separate of course.So doe this hierarchy look right
>
> Architecture Guide ---> Module list ----> Module technical detail
> ^
> |
> User Guide ---> Implementation/Binding/Databinding... list --> Extension
> User Guide
>
> We could probably tie the two together as you suggest by indicating
which
> modules are used to implement an Implementation/Binding/Databinding
>
> Simon
>
Hi
1/ Architecture Guide.
It was just that the text here has an M2 feel about it, i.e. it refers to
things like Kernel which is not a term used in the code now (core does
appear though). So I think we should go with an architecure page that
describes how the Tuscany runtime is put together. I prefer the level of
detail that you have put on the kernel specific architecture page [2]
although of course this need updating as well. From this wide ranging
discusion of kernel we can link, in appropriate places, to the technical
details of the inidividual modules. So, expanding on a previous post, I
would anticipate something like the following set of pages
Architecture 1000ft [1]-----------------
| |
| \/
| Module Detail [3]
| /\
\/ |
Architecture Guide [2]-----------------
[1]
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Modulization+Design+Discussions<http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Modulization+Design+Discussions>
[2]
http://cwiki.apache.org/confluence/display/TUSCANY/Java+SCA+Kernel+Architecture+Guide
[3] Technical detail of each module - e.g.
http://cwiki.apache.org/TUSCANY/binding-ws.html
I am of course happy to help try and work this out but didn't want to dive
in moving links about while others are doing the same. Could get very
confusing.
2/ Developer guide
This comment was just stating a preference. I just liked the idea of having
a user guide and a developer guide. I felt that "getting involved" sounded
like it should be talking about mail lists and irc's etc rather than the
details of the development process. If people are generally happy with the
getting involved then its far more important to get the content there than
debate what it's called ;-)
Simon
