[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SRU Protocol Model Terminology
Hi: Following on yesterday's call I made some remarks about the SRU protocol model terminology. I am very chary about introducing new (or seemingly new) terminology - even where terms may be explained in the text. We should aim to avoid lessons in algebra. * Existing terminology CA client application SE search engine SRUP/C SRU protocol module at the client SRUP/S SRU protocol module at the server PRQ searchRetrieve protocol request PRS searchRetrieve protocol response LLP lower level protocol I am wondering if the following changes might be in order. 1. Retain CA/SE. (Looked for symmetry but gave up.) 2. Drop the specious "P" in SRUP/C, SRUP/S. The term "SRUP" is horrendous. 3. Use REQ and RES (or RESP) for PRQ, PRS as these are readily familiar terms in client/server architectures. And note that we should avoid the term "searchRetreive protocol" and instead use the term "SRU protocol". 4. Let's not be coy about the transport protocol - it *is* HTTP. I worry that introducing a new layer of abstraction (through the term LLP) is a generalization too far. If we need to abstract we should probably use "transport protocol" rather than "lower level protocol" because we are still using SRU semantics but over an HTTP transport layer. That would lead to the following proposal from me: * Suggested terminology CA client application SE search engine SRU/C SRU protocol module at the client SRU/S SRU protocol module at the server REQ SRU protocol request RSP SRU protocol response HTTP HTTP protocol (for transport) I have taken a rough cut at a revised architecture diagram (see .png attached) with new labelling, client/server processes more clearly indicated, and a cloud for topicality. If this is deemed to be in any way useful I could always aim to improve. Cheers, Tony ******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ********************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]