Software Engineering for Internet Applications - Student Community

equest headers and then parse out the Cookie header or perhapsyou'll have an API that makes it easy to get the value of a particularcookie. Note that you can expire a cookie by reissuing it with anexpiration date that has already passed.Hint 1: It is possible to build this system using an ID cookie for thebrowser and keeping the set of killed quotations in the RDBMS.However, if you're not going to allow users to log in and claim theirprofile, there really isn't much point in keeping data on the server.Hint 2: It isn't strictly copacetic with the cookie spec, but browsersaccept cookie values containing spaces. So you can store the killedquotations as a space-separated list if you like.Hint 3: Don't filter the quotations in your Web script. It is generally asign of incompetent programming when you query more data fromthe RDBMS than you're going to display to the end-user. SQL is avery powerful query language. You can use the NOT IN feature toexclude a list of quotations.Exercise 10: Publishing data in XMLAs you learned above from querying bookstores, data on the Webhave not traditionally been formatted for convenient use by computerprograms. In theory, people who wish to exchange data over theWeb can cooperate using XML, a 1998 standard from the WebConsortium (http://www.w3.org/XML/). In practice, you'll be hardpressedto get any XML-based cooperation from the average Website right now (2003). Fortunately for your sake in completing thisproblem set, you can cooperate with your fellow students: the overallgoal is to make quotations in your database exportable in astructured format so that other students' applications can read them.Here's what we need in order to cooperate:38• an agreed-upon URL at everyone's server where thequotations database may be obtained: "/basics/quotationsxml"• an agreed-upon format for the quotations.[In point of fact, we could avoid the need for prior agreement bysetting up infrastructures for service discovery and by employingtechniques for self-describing data -- both of which we'll deal withlater in the semester -- but we'll keep things simple for now.]plenty to flag major problems. Review it at least once every twoweeks.Date of most recent face-to-face meeting withClientDate of most recent telephone meeting with ClientDate of most recent face-to-face meeting withSponsorDate of most recent telephone meeting withSponsorHave engagement letter (see below) signed byClient and Sponsor?Current specs signed by Client and Sponsor?Have weekly update meeting minutes, signed byClient? (includes changes requested / agreed /under discussion)Estimated delivery date vs. committed delivery dateEstimated budget vs. committed budgetClient mood (unhappy to happy)Team moodMood of the average user who has tried theapplicationA good engagement letter covers at least the following subjects:• overall description of client situation and need• summary of application to be built• deadlines• budgets• mutual obligations• other terms311