Talk:MIAS DIY
From Schoolforge-UK
Steve Lee observed: "The original SIF is based on a message passing architecture. This has significant advantages for scalability, decoupling and ruggedness. Are we proposing to lose that completely or keep it as the core?"
- The web is certainly scalable and decoupled, but not so rugged in terms of passing data. But I can't answer that question - I'm just trying to present technical stuff to the layman. If REST means sticking with HTTP, XML and URLs, does that mean losing a message passing architecture?
- if REST does not permit a message passing architecture: then we cannot use it to achieve the ruggedness of the original SIF. How could we overcome that?
- if REST does permit a message passing architecture: how do we realise the SIF specification within the scope of a FLOSS project?
JohnIngleby
Message passing
Well Jabber as IM is message based (XML streaming). Perhaps the question is how well can REST interfaces fit with a message passing core. SteveLee
Reliable delivery in HTTP
When trying to get two difference applications to communicate with each other, it's often useful to simply know when a communication breakdown has occurred, rather than finding more reliable ways for the systems to communicate.
In any case, the perfect method of communication doesn't exist, many things can go wrong: cleaners pulling out plugs, floods, overheated CPUs, failed hard discs, etc.
Paul Prescod suggests using message IDs to achieve reliable HTTP POSTs.
If an application sends a message requesting certain data along with an message ID, then after a time it can decide whether the requested data has (or has not) arrived with the associated message ID. The application can then initiate some kind of error action: either re-send the request (ignoring the previous request) or issue an appropriate application error. It's like sending an email message confirmation tag.
Of course, if this goes on all the time, then you have to look at improving the comunication link!
