Re: Proposal: A Registry Browser GUI tool

[David RR Webber <Gnosis_@compuserve.com>]

Nick,

OK - having discussed this earlier with Farrukh, and made some
revisions to the draft document I had - yes TRP can be used
for certain scenarios and requirements - that's not my issue.

What I want it the flexibility to use a tailored RegRep mechanism
where it makes sense - Reg <-> Reg comm's is one obvious
area.  Even within this scenario I'm seeing that  http/MIME 
make sense, just that we will need error handling, enveloping and
interaction models that are specific and TRP will be clumsy in 
those scenarios.

What we do want is commonality of philosophy and I believe
we have that - that someone looking at the complete set of 
TRP and RegRep will see the threads and same items 
running through.   At this point I don;t think we can lock ourselves
into TRP completely for everything.  We have to be able to 
evaluate here based on the requirements.  Clearly RegRep 
requirements are related but different.

Here's another thought - we may end up backing in TRP some
of the stuff coming out of RegRep - that would be cool too.

Thanks, DW.
=======================================================
Message text written by Nicholas Kassem
> 
David,

Clearly you don't see the regrep Client and associated services as just 
another ebXML Business Process (granted that it is a specialized BP).

I don't see any reason why a WAP enabled device can't be a consumer of 
regrep services. But I wouldn't put a Cell Phone at the design center and 
gut all the ebXML TRP functionality to meet the needs of this single 
device, I would proxy the client and expose it as an ISP service. Whether 
TPA assembly is likely to happen over a shoe phone is an entirely different

matter - personally I think not.
<snip>

What makes RegRep so specialized an application that it doesn't need ebXML 
TRP - can we get passed this obsession with the Client Run-time environment

- is there a technical basis for the position you are taking ?

Nick
<