[Development] Request for a sandbox area: Replicant

[md at rpzdesign.com]

Bret:

I am certainly open to Ford Motor Company sponsoring my flight to
wherever this summit is taking place and we can dispose of the problem
of my failure to attend.

My talk would be titled, "How Bill Gates dreamed of using RPC to court
his future yet unseen wife"

Hell, that might even be qualify for a TED talk as well.

I promise I will buy you a beer when I land.

My usage of the term "HELL" probably indicates that I am a crude
American without the fine polish of our European counterparts, like our
allies at Digia, with whom I have true respect.

To put it into automotive terms, I likely drive a F-150 and not a Prius.

But I will continue with this monologue until they cut me off.

There is the local case and the remote case across the myriad number of
devices.  There are just a lot of extra variations in IPC across
Desktop, Android, and IOS.

For example on Local: http://www.slideshare.net/jserv/android-ipc-mechanism

For Remote, I think you are left with UDP broadcast/multicast for
discovery/reconnection purposes.

The reason why RPC died and HTTP/REST dominates is the simple fact that
HTTP/REST is SIMPLE.  Not 10 million bloody incomprehensible parameters
like RPC.

Whey does SOAP continue to decline?  Extra complexity for little or no
gain.  Who wants to worry about WSDL?

With HTTP/REST, If you do not have network connectivity, the ergonomics
are dictated by a simple timeout and an HTTP/404 error or something like
that.

WIth RPC, you could NEVER tell why it was not working.  But you were
SURE it was NOT working.  Sometimes, you were not sure it WAS working.

Let alone a human being operator getting meaningful feedback
and the library supporting such simple feedback.

What does error WM_ERRORBASE+IPCERRORBASE+CUSTOMIPCERROR mean?

So be very careful in getting distracted by all the IPC unification work
just to make replication function across device platforms.  There may be
an easy alternative for both local and remote cases.

I know, I use UDP broadcast for both Android and IOS because it just
works. And the code is SIMPLE.

Cheers,

md
San Vito
Costa Rica





On 6/1/2014 8:30 PM, Stottlemyer, Brett (B.S.) wrote:
>> This cross process stuff is starting to feel like 1996 and remote procedure RPC 
>> calls, now using QT signals and slots. "<drool>" again for effect.
>>
>> One could review the history of microsoft and the fine RPC mechanisms that 
>> turned out to be mostly unusable, or maybe just unused.
>>
>> Keep the optimism in check folks. We have a lot of devices now in the mix, not just Win32.
> 
> LOL.  
> 
> I understand this is a proposal and is code you've never seen.  So it is impossible for you to tell, based on my description, if it actually does any of the stuff I say it does.  It could be the "killer app" Charley is looking for, or a total "who cares" as you seem to.
> 
> I am going to QtCS to talk about it, and I'm sure I will be addressing concerns like yours.  /me wonders what Thiago's first question will be....
> 
> BUT - unless you are going to be at QtCS, I'd appreciate it if you took the time to express what you think Replicant needs to do to be successful, or at least what you think caused other RPC mechanisms to fail....  While I understand the sentiment, it would be helpful to understand what you think Replicant can do to keep falling into the same trap.  Or are you of the opinion that an easy/sound RPC mechanism isn't possible?
> 
> Thanks,
> Brett
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>