Home » Archived » Test and Performance Tools Platform (TPTP) » about the old and new agent controller
|
| Re: about the old and new agent controller [message #72931 is a reply to message #72896] |
Fri, 02 June 2006 14:11   |
 Michael Iles
Messages: 7
Registered: July 2009 |
Junior Member |
|
|
Ben.xu wrote:
> Anybody know the difference of the old and the new AC ?
> On 4.2, IS there anyfunction old can do but new can't do
> or new can do but old can't do?
> OR, is there any plan to obsolete the old AC?
>
> just can't understand why we need two AC's? why not use a unique one, it
> will be better for the user.
As I understand it, the new AC is a re-architecting of the old AC to
introduce flexibility into the transport protocols, a new interface for
agents, allow multiple ACs to run side-by-side, etc. (There's an old NG
post here:
http://www.eclipse.org/newsportal/article.php?id=1072&gr oup=eclipse.tptp.)
In recent 4.2 builds there's also a compatibility layer both for the
workbench to talk to the AC (so a 4.1 workbench can talk to a NT AC as
if it's an old AC), and also between agents and the AC (so agents
written to the old interface can talk to a new AC as if it's an old
one)... so the migration from old to new AC should be transparent to
both clients and agents.
My understanding is that the old AC will be obsoleted once the kinks in
the AC compatibility mechanisms are worked out, but I don't speak for
the TPTP team.
Mike.
|
|
|
| Re: about the old and new agent controller [message #73136 is a reply to message #72931] |
Sat, 03 June 2006 00:11 |
Karla Callaghan
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Mike gives a pretty good description. I'm in the midst of writing up a
comparitive explanation of old and new AC's to help answer questions like
yours which I expect to have ready next week.
We certainly don't need or want 2 AC's in the long run, the maintenance
burden is awful. However, making the switch across all platforms at the
same time was too big an effort to contain in one release, so we will be
migrating platforms as quickly as resources allow. When the new AC is on
all the platforms, the old AC becomes obsolete. To make the transition
period bearable for products relying on the old AC, we added a backwards
compatibility layer to the new AC. This is expected to become obsolete too.
A brief comment on functional differences:
1) Using the new API offered with the new AC, a client can discover
available agents at runtime.
2) Both C++ and Java API's exist for the new AC, only Java is available for
old API
3) The file transfer services offered through the old API are richer. The
new file transfer agent handles just the basic put and get of files at this
time
4) Security when connecting to the AC is only offered through the old API at
this time
5) By providing a unique config file for each, multiple new AC's can run at
the same time
6) Dynamic discovery of peer agent controllers is only offered through the
old API at this time
Plans on when the gaps get filled will occur during upcoming release
discussions. You can let us know what's important to you by entering and
voting for features found in bugzilla during planning cycles.
-Karla
"Michael Iles" <michael.iles@cognos.com> wrote in message
news:e5pgvj$c0p$1@utils.eclipse.org...
> Ben.xu wrote:
>> Anybody know the difference of the old and the new AC ?
>> On 4.2, IS there anyfunction old can do but new can't do
>> or new can do but old can't do?
>> OR, is there any plan to obsolete the old AC?
>>
>> just can't understand why we need two AC's? why not use a unique one, it
>> will be better for the user.
>
> As I understand it, the new AC is a re-architecting of the old AC to
> introduce flexibility into the transport protocols, a new interface for
> agents, allow multiple ACs to run side-by-side, etc. (There's an old NG
> post here:
> http://www.eclipse.org/newsportal/article.php?id=1072&gr oup=eclipse.tptp.)
>
> In recent 4.2 builds there's also a compatibility layer both for the
> workbench to talk to the AC (so a 4.1 workbench can talk to a NT AC as if
> it's an old AC), and also between agents and the AC (so agents written to
> the old interface can talk to a new AC as if it's an old one)... so the
> migration from old to new AC should be transparent to both clients and
> agents.
>
> My understanding is that the old AC will be obsoleted once the kinks in
> the AC compatibility mechanisms are worked out, but I don't speak for the
> TPTP team.
>
> Mike.
|
|
| |
| Re: about the old and new agent controller [message #77474 is a reply to message #73136] |
Fri, 14 July 2006 22:31 |
Karla Callaghan
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Here is the much-delayed posting of the link to the document I referred to
below.
http://www.eclipse.org/tptp/platform/documents/newtechAC/dat a_collection_framework_intro/c_dc_fmwk_new_ac_dg.html
Regards,
Karla
"Karla Callaghan" <karla.callaghan@intel.com> wrote in message
news:e5qk2t$rnn$1@utils.eclipse.org...
> Mike gives a pretty good description. I'm in the midst of writing up a
> comparitive explanation of old and new AC's to help answer questions like
> yours which I expect to have ready next week.
>
> We certainly don't need or want 2 AC's in the long run, the maintenance
> burden is awful. However, making the switch across all platforms at the
> same time was too big an effort to contain in one release, so we will be
> migrating platforms as quickly as resources allow. When the new AC is on
> all the platforms, the old AC becomes obsolete. To make the transition
> period bearable for products relying on the old AC, we added a backwards
> compatibility layer to the new AC. This is expected to become obsolete
> too.
>
> A brief comment on functional differences:
> 1) Using the new API offered with the new AC, a client can discover
> available agents at runtime.
> 2) Both C++ and Java API's exist for the new AC, only Java is available
> for old API
> 3) The file transfer services offered through the old API are richer. The
> new file transfer agent handles just the basic put and get of files at
> this time
> 4) Security when connecting to the AC is only offered through the old API
> at this time
> 5) By providing a unique config file for each, multiple new AC's can run
> at the same time
> 6) Dynamic discovery of peer agent controllers is only offered through the
> old API at this time
>
> Plans on when the gaps get filled will occur during upcoming release
> discussions. You can let us know what's important to you by entering and
> voting for features found in bugzilla during planning cycles.
>
> -Karla
>
> "Michael Iles" <michael.iles@cognos.com> wrote in message
> news:e5pgvj$c0p$1@utils.eclipse.org...
>> Ben.xu wrote:
>>> Anybody know the difference of the old and the new AC ?
>>> On 4.2, IS there anyfunction old can do but new can't do
>>> or new can do but old can't do?
>>> OR, is there any plan to obsolete the old AC?
>>>
>>> just can't understand why we need two AC's? why not use a unique one, it
>>> will be better for the user.
>>
>> As I understand it, the new AC is a re-architecting of the old AC to
>> introduce flexibility into the transport protocols, a new interface for
>> agents, allow multiple ACs to run side-by-side, etc. (There's an old NG
>> post here:
>> http://www.eclipse.org/newsportal/article.php?id=1072&gr oup=eclipse.tptp.)
>>
>> In recent 4.2 builds there's also a compatibility layer both for the
>> workbench to talk to the AC (so a 4.1 workbench can talk to a NT AC as if
>> it's an old AC), and also between agents and the AC (so agents written to
>> the old interface can talk to a new AC as if it's an old one)... so the
>> migration from old to new AC should be transparent to both clients and
>> agents.
>>
>> My understanding is that the old AC will be obsoleted once the kinks in
>> the AC compatibility mechanisms are worked out, but I don't speak for the
>> TPTP team.
>>
>> Mike.
>
>
|
|
|
Goto Forum:
Current Time: Tue Apr 16 19:10:44 GMT 2024
Powered by FUDForum. Page generated in 1.75906 seconds |
] 
Search
Help
Register
Login
Home
