ant elder wrote:
I don't think we should do this yet. We've only just put Node2 out in a
release and users have just started to move from the SCADomain APIs to
it so to turn around an immediately deprecate it doesn't give a very
good user experience, and one of our users has even replied to this
thread saying that.
And I don't think we should deprecate it till we know what the final
stable API is and I don't think we know Node2 is it yet. Its not great
you need to cast to the SCAClient so thats one thing that could be
improved, there's the various spec group proposals going on for the
client APIs that will be resolved at some point which we'll need to make
updates for, I've got a work item i need to do in the next couple of
months on the client APIs and that will likely require changes. Just
yesterday there was the new proposal for how our samples should be using
the SCA programming model. All that to me says we should wait a bit for
things to settle down before making breaking changes or deprecating
anything, is there any real need to rush this in?
...ant
On Tue, Aug 19, 2008 at 12:27 AM, Raymond Feng <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
OK. Instead of renaming, I'll add SCANodeFactory/SCANode and leave
the SCANode2Factory/SCANode2 deprecated. Existing samples or itests
will be migrated to use SCANodeFactory/SCANode. Meanwhile I'll
change the maven artifact ids from node2-xxx to node-xxx.
Thanks,
Raymond
From: ant elder
Sent: Monday, August 18, 2008 6:17 AM
To: [email protected] <mailto:[email protected]>
Subject: Re: Rename Node2/node2 to Node/node in trunk
I agree with Dave and think we should leave this to try for a while
before settling on it as a long term final api.
...ant
On Sat, Aug 16, 2008 at 6:11 PM, Raymond Feng <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi,
Thank you for sharing your thought. Which set of Tuscany APIs are
you using? SCADomain or SCANode2?
I agree that we have to be extra careful to maintain the
compatibility for APIs. But we also have to bite the bullet
sometimes as the project evolves, otherwise it will create even more
compatibility issues and confusions over time. Unfortunately we have
been in this half-compatibility mode for a while and that's probably
why it becomes difficult to follow as we give the users too many
choices :-(. Worth to point out is that I proposed this change for
the trunk instead of 1.3.x branches.
If most of the users still use the SCADomain (due to the fact that
most of our samples are using SCADomain without deprecation), it's
probably better to rename the SCANode2 sooner than later before it
gets popular :-). YMMV.
Thanks,
Raymond
--------------------------------------------------
From: "Dave Sowerby" <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
Sent: Saturday, August 16, 2008 12:10 AM
To: <[email protected] <mailto:[email protected]>>
Subject: Re: Rename Node2/node2 to Node/node in trunk
Hi Guys,
I agree with Ant - as a user of Tuscany for quite some time I've found
it difficult keeping up with the Node api changes - I concur with also
that it would be nice to maintain this current api for a while and
then perhaps look into settling on some longer term final api?
Cheers,
Dave.
--
Dave Sowerby MEng MBCS
On Sat, Aug 16, 2008 at 7:45 AM, ant elder <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Sat, Aug 16, 2008 at 1:12 AM, Raymond Feng <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi,
We now have the Node APIs in the code base with 2 suffix, such as
SCANode2, SCANode2Factory and tuscany-node2-api, tuscany-node2-impl. I
propose that we rename them back to Node/node.
If there is no objection, I'll do it early next week.
Thanks,
Raymond
We've only just put these out in a release as Node2 and said they
were the
new and better replacement APIs our users should now be using, so i
think we
need to keep that working for a while so we shouldn't rename them as
it will
break users code.
...ant
Sorry for the delayed response. I have been on vacation for the last week
and I am trying to catch up with my backlog on the ML. I agree that we
should not move too quickly on this renaming. We should wait to get more
experience with these APIs before we declare them final and stable.
Simon
