[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] SRU Protocol Model Terminology
Hi Ray: Agreed. Interaction between SRU/S and SE is unspecified and may not be a simple request/response (as I had shown) - and, in fact, the SE might not even be consulted at all if a result set is maintained at SRU/S (i.e. step 4 may not actually occur). Have attached a revised (and renumbered) figure. Let me know if there are any problems. Cheers, Tony On 21/1/10 22:44, "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote: > I just took a quick look at this (sorry, I've been a bit slow lately) and > I'm completely happy with it EXCEPT for one detail. > > In my diagram, note that step 4 is a two-way interaction. I saw no reason to > break it into two steps. Thus "the SRU/S interacts with the SE" can be > modelled as a single step. This is different from (and not symmetric with) > the interaction on the other side between the CA and SRU/C because those are > two steps that occur at different times, namely the first and last step. > (Note that in my diagram there is an error, a missing arrow representing > step 1.) > > Tony if you agree, could you redraft this: combine steps 4 and 5 into a > single step (double sided arrow) and renumber, total 7 steps. Then I'll put > it in the document. Otherwise it's fine. > > Thanks. > > --Ray > > ----- Original Message ----- > From: "Hammond, Tony" <t.hammond@nature.com> > To: "OASIS SWS TC" <search-ws@lists.oasis-open.org> > Sent: Tuesday, January 12, 2010 11:22 AM > Subject: [search-ws] 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 >> ***************************************************************************** >> *** >> > > > ------------------------------------------------------------------------------ > -- > > >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > ******************************************************************************** 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]
