Ok,so I decided to learn creating the REST services using WCF.
First I had to download the following :-

a) WCF REST Starter Kit Preview 2

After you have installed the starter kit,you should see a set of templates under “File > New > Project”:-

1) What is REST?
    a)Definition
    b)Tenets of REST ful services
    c)High REST and Low REST ful service   (“ 302- Object moved”  :-) - to the last point I need a lot to learn before I get back to this)
    d)Ways to develop REST ful services.

Question :- Are you comfortable confident in in REST for what you have read till now?

1. 2) REST ful services using WCF
       a) How to map REST verbs with HTTP verbs
       b) Reading HTTP specification for the GET,POST,PUT and DELETE

Question :- Are you comfortable confident in in REST for what you have read till now?

    c) How to create a REST ful service?
        i) Get comfortable with the different templates of the REST starter kit.
        i) Making use of GET,POST,PUT and DELETE
        ii) When to use POST,PUT and DELETE
            Get the examples.
Question :- Are you comfortable confident in in REST for what you have read till now?
    d) How to consume a REST ful service?
        Create examples which do the following:-
            i) Use Yahoo search
            ii) Use Google search
            iii) Use Twitter
    e) Caching with REST
    f) Database operations with REST
Question :- Are you comfortable confident in in REST for what you have read till now?

1) c)High REST and Low REST ful service
Reading material :-
a) http://www.mnot.net/blog/2006/03/20/hi_lo
b) http://lesscode.org/2006/03/19/high-low-rest/

I started here at 12:33 PM 6/6/2009:-

What is a Service ?
- Means to get the resources get some operations done
What is REST ?

REST is an architectural style for building resource oriented services by defining the resources that implement uniform interfaces using standard HTTP verb LIKE Get,POST,PUT and DELETE.

Tenets of REST ful service:-
1)  Use the URI to locate the resources.
2)  Use the verbs to work with resources.
Get the resource :- GET
Do something with the resource :- POST,PUT,DELETE
3) The content type of the data sent to/received from the services is the object model
XML,JSON
4) Result of a service request is nothing but the HTTP result code.
200- OK,404-Not found

This is from Ron Jacobs:-
Internet is a web of pages,right? and has following characteristics:-
A) Simple and Open

Addressing scheme – URI
Application Protocol – HTTP
Representational format – XHTML
Response codes – HTTP status

B) Scales best when

Stateless
Cached

C) Hyperlinks!- and right, internet would just suck if there are no links!

If you look at how we write web services,you see that we follow SOAP which in no doubt an incredible way of interoperability between the clients and the services.
Now HOLD ON.. before I say something anything against SOAP,why not consider something which also does the same/similar thing in a simplistic way. This makes us look at the ways how we can make “web of services” work like the “web of pages”.

    a) How to map REST verbs with HTTP verbs
    b) Reading HTTP specification for the GET,POST,PUT and DELETE

Have a look :-
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Look at sections 9.3 for GET,9.5 for POST ,9.6 for PUT and 9.7 for DELETE. Here is the following:-

 

9.3 GET

The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.

The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.

The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section 14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.

The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.

See section 15.1.3 for security considerations when used for forms.

9.5 POST

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

      - Annotation of existing resources;

      - Posting a message to a bulletin board, newsgroup, mailing list,
        or similar group of articles;

      - Providing a block of data, such as the result of submitting a
        form, to a data-handling process;

      - Extending a database through an append operation.

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.

If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

POST requests MUST obey the message transmission requirements set out in section 8.2.

See section 15.1.3 for security considerations.

 

9.6 PUT

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,

it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server.

HTTP/1.1 does not define how a PUT method affects the state of an origin server.

PUT requests MUST obey the message transmission requirements set out in section 8.2.

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.

9.7 DELETE

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

Although HTTP fully supports CRUD, HTML 4 only supports issuing GET and POST requests through its various elements. This limitation has held Web applications back from making full use of HTTP, and to work around it, most applications overload POST to take care of everything but resource retrieval. HTML 5, which is currently under development, plans to fix this by adding new support for PUT and DELETE.

GET, HEAD, and OPTIONS are all examples of safe methods that aren’t intended to have side effects. All safe methods are also idempotent, as are PUT and DELETE, so you should be able to repeat them multiple times without harm. The POST method is something of a special case. According to the HTTP specification, POST should be used to provide a representation that can be treated as a subordinate of the target resource. For example, you could POST a new blog entry to the URI representing the blog feed, causing a new blog entry to be added to the feed. POST can also be used to process a block of data such as the data transmitted by an HTML form. The actual function performed by the POST method is defined by the server. Therefore, POST cannot be considered safe or idempotent by clients.

HTTP also defines a suite of standard status codes that specify the result of processing the request. Status codes are organized into ranges that mean different things. For example, status codes in the 200 range mean “successful” while status codes in the 400 range mean the client issued a bad request. Figure 2 describes each status code range and provides a few examples of common status codes.

So,I started studying Assembly Language.It is very silly to say that it is interesting language at the first glance when you look at those hexadecimal codes with some weird command like MOV on the command prompt and also when you are coming from working on all the high level languages like C++,Java and C#.However,there is no denial to the fact that you start to learn a lot about the CPU architecture especially "registers". Most important thing is Assembly language is just one level up from the machine language and hence are bound to be real fast compared to the high level (read "layered/abstract/sugar coated") languages. I would be really cool if I can get my fundamentals straight out here and then get into something real deep. I am sure it would help me in writing efficient code (or better understanding) in the language I speak,C# ! :-) Why Assembly language all of a sudden?? Ok,ok,let me confess,it is one of the papers in my MS (Computer Science) degree. :-). I realized that this subject (which I have never worked on),deserves some time to be understood and and there is an opportunity to learn a new thing. See..I am thinking! :-)

I started with real basic introduction and a good place is http://www.swansontec.com/sprogram.htm. Which basically says that the Assembly language is a mnemonic language i.e. a set of instructions mapping to the machine language. It has a pretty small but basic example of creating a assembly language program.

I read about the Assemblers and Loaders which,respectively are responsible for converting the Assembly language to the machine language and loading the machine language to the memory.

rawayat hai ke zindagi gahana hai
ya heera hai aur chatate rahana hai
Ke lamhon main marne kaa dastoor hai-2

If you see a spelling mistake and ,please ldo me a favor to let me know and I would correct the same..

Thanks,
Ashish

Very sleek open source PDF creation library built in .NET and its up for commercial use.

http://www.codeproject.com/KB/graphics/giospdfnetlibrary.aspx

(NameValueCollection)ConfigurationManager.GetSection("applicationSettings/ConnectionStrings");

#region Remove XML comments
System.Xml.XPath.XPathNavigator path = xmlDoc.SelectSingleNode("w:document",xmlNSMgr).CreateNavigator();
System.Xml.XPath.XPathNodeIterator commentsIterator = path.SelectDescendants(System.Xml.XPath.XPathNodeType.Comment,false);
if (commentsIterator.Count > 0)
{
while (commentsIterator.MoveNext())
{commentsIterator.Current.DeleteSelf();}}
#endregion

For the following XML:-(We needed to remove "<!--  Generated by Aspose.Words for .NET 4.4.1.0   --> ")

  <?xml version="1.0" encoding="utf-8" standalone="yes" ?>
- <w:document xmlns:ve="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing" xmlns:w10="urn:schemas-microsoft-com:office:word" xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" xmlns:wne="http://schemas.microsoft.com/office/word/2006/wordml">
- <!--  Generated by Aspose.Words for .NET 4.4.1.0
  -->
- <w:body>
- <w:p>
- <w:r>
- <w:rPr>
  <w:b />
  <w:color w:val="FF0000" />
  <w:sz w:val="24" />
  </w:rPr>
  <w:t>Evaluation Only. Created with Aspose.Words. Copyright 2003-2007 Aspose Pty Ltd.</w:t>
  </w:r>
  </w:p>
  </w:body>
  </w:document>