[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Proposal: A Registry Browser GUI tool
I think this thread has gone on long enough on this list and should probably be moved to regrep / TRP lists. I am sensitive to the common syndrome of "if all you have is a hammer everything looks like a nail". I guess what I need to see is a *studious* depiction of the regrep "nail". If TRP has specified the wrong capabilities then we should fix it. Until I see a regrep *specification* (as opposed to a regrep POC proposal) I guess I will have to (in the POC context) push this issue to the back burner. Nick At 11:27 PM 9/14/2000 -0400, David RR Webber wrote: >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 ><
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC