Open Market, Inc.
April 1996
The surge in the use of the Web by business has created a tremendous need for server extension applications that create dynamic content. These are the applications that will allow businesses to deliver products, services, and messages whose shape and content are in part determined by the interaction with, and knowledge of, the customers to which they are delivered.
This important movement away from static Web content is pushing the limits and exposing the weaknesses of the environment in which these applications are currently bound: CGI (Common Gateway Interface). Most importantly it does not offer the performance these applications require. A new communication infrastructure is needed to connect Web servers with these new applications. This is what led Open Market to develop FastCGI.
FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI, without introducing the overhead and complexity of proprietary APIs (Application Programming Interfaces).
This paper assumes that the reader has basic familiarity with Web technology and developing Web applications.
The de facto standard interface for Web server applications is CGI, which was first implemented in the NCSA server. CGI has many benefits:
CGI also has some significant drawbacks. The leading problem is performance: Since a new process is created for each request and thrown away when the request is done, efficiency is poor.
CGI also has limited functionality: It only supports a simple "responder" role, where the application generates the response that is returned to the client. CGI programs can't link into other stages of Web server request processing, such as authorization and logging.
In response to the performance problems for CGI, several vendors have developed APIs for their servers. The two most notable are NSAPI from Netscape and ISAPI from Microsoft. The freely available Apache server also has an API.
Applications linked into the server API may be significantly faster than CGI programs. The CGI startup/initialization problem is improved, because the application runs in the server process and is persistent across requests. Web server APIs also offer more functionality than CGI: you can write extensions that perform access control, get access to the server's log file, and link in to other stages in the server's request processing.
However, APIs sacrifice all of CGI's benefits. Vendor APIs have the following problems:
The FastCGI interface combines the best aspects of CGI and vendor APIs. Like CGI, FastCGI applications run in separate, isolated processes. FastCGI's advantages include:
The following sections describe the FastCGI interface, protocol, application library, and support in Open Market's WebServer products.
The functionality provided by the FastCGI interface is very similar to that provided by CGI. To best understand the FastCGI protocol, we review the CGI interface here. Basic CGI request processing proceeds as follows:
FastCGI is conceptually very similar to CGI, with two major differences:
Request processing in a single-threaded FastCGI application proceeds as follows:
FastCGI applications can run locally (on the same machine as the Web server) or remotely. For local applications, the server uses a full-duplex pipe to connect to the FastCGI application process. For remote applications, the server uses a TCP connection.
FastCGI applications can be single-threaded or multi-threaded. For single threaded applications, the Web server maintains a pool of processes (if the application is running locally) to handle client requests. The size of the pool is user configurable. Multi-threaded FastCGI applications may accept multiple connections from the Web server and handle them simultaneously in a single process. (For example, Java's built-in multi-threading, garbage collection, synchronization primitives, and platform independence make it a natural implementation language for multi-threaded FastCGI applications.)
FastCGI's ability to run applications remotely (over a TCP connection) provides some major benefits. These benefits are described in this section, along with some of the security issues that affect remote FastCGI applications.
Applications that run on organizational (external) Web servers and depend on internal databases can be a challenge to administer. Figure 1 shows a typical organization, with an external Web server, a firewall restricting access to the internal network, and internal databases and applications.
With CGI and vendor APIs, the application has to run on the Web server machine. This means the server administrator has to replicate the necessary database information onto the system hosting the Web server (which may be difficult to do in an automated way without compromising firewall security). Or, the administrator may build a "bridge" that allows access through the Web server to internal databases and applications (which is effectively re-inventing remote FastCGI).
With remote FastCGI, the applications can run on the internal network, simplifying the administrator's job. When used with appropriate firewall configuration and auditing, this approach provides a secure, high-performance, scalable way to bring internal applications and data to the external network.
For resource-intensive CGI and API applications, the Web server machine quickly becomes the bottleneck for overall throughput. The usual way to solve this performance problem is to buy a bigger, faster Web server machine, or to partition the Web site across several Web servers.
With remote FastCGI, the resource-intensive applications can be moved off the Web server machine, giving the server administrator additional flexibility in configuring the Web server. The administrator can configure FastCGI applications "behind the scenes" without having to change any content links or the external view of the Web site. The administrator can use several smaller, inexpensive server machines for applications, and can tailor each machine to the application it is hosting.
The two security issues with remote FastCGI connections are authentication and privacy. FastCGI applications should only accept connections from Web servers that they trust (the application library includes support for IP address validation). Future versions of the protocol will include support for applications authenticating Web servers, as well as support for running remote connections over secure transport protocols such as SSL or PCT.
This section offers a brief introduction to the protocol used on the connection between the Web server and FastCGI application. Most application developers will use the FastCGI application library and won't have to worry about the protocol details. However, specialized applications are free to implement the FastCGI protocol directly.
FastCGI uses a simple packet record format on the connection between the application and the Web server. The same record format is used in both directions and is outlined in Figure 2.
The protocol version field specifies the version of the FastCGI protocol that is in use. The type field specifies the type of the record (described in the following section). The request ID identifies this record to a particular request, allowing multiple requests to be multiplexed over a single connection. The data length field specifies the number of data bytes that follow.
The different FastCGI packet types are:
| FCGI_PARAMS | Used for sending name/value pairs (CGI environment variables) from the Web server to the application. |
| FCGI_STDIN | Used for sending the standard input from the Web server to the application. |
| FCGI_DATA | Used for sending filter data to the application (for more information, see the filter role described on page 7.) |
| FCGI_STDOUT | Used to send standard output from the application to the Web server. |
| FCGI_STDERR | Used to send standard error information from the application to the Web server. |
| FCGI_END_REQUEST | Ends the request (can be sent by either the server or the application). |
For complete protocol details, see the FastCGI Protocol Specification, available from the Web site listed at the end of this paper.
A major problem with CGI is its limited functionality: CGI programs can only provide simple responses to requests. FastCGI provides expanded functionality with support for three different application "roles":
Other roles will be defined in the future. For instance, a "logger" role would be useful, where the FastCGI program would receive the server's log entries for real-time processing and analysis.
The roles are described in more detail in the following sections.
FastCGI's Responder role is identical to the functionality provided by CGI today. When a request comes into the server, the FastCGI program generates the response that's returned to the client (typically an HTML page).
The Filter role allows a FastCGI application to process a requested file before it is returned to the client.
Let's assume that the Web server is configured so that all files with the .sgml extension are processed by a SGML-to-HTML FastCGI filter application, and the user accesses the following URL:
/document.sgml
After the Web server makes an access control decision and maps this URL to a content file, it invokes the FastCGI filter application with this file available as input. The FastCGI program's HTML output is sent back to the client, just as in the responder role. The process is outlined in Figure 3.
Filter applications can significantly improve performance by caching filter results (the server provides the modification time in the request information so that applications can flush the cache when the server file has been modified).
The Filter role is useful for:
The Authorizer role allows a FastCGI application to make an access control decision for a request. The FastCGI application is invoked with all of the request information, just as in the Responder role. If the authorizer application generates a "200 OK" HTTP result, the Web server assumes that access is allowed and proceeds with the request. (The Web server may process other access checks, including other FastCGI authorizers, before access is ultimately allowed.) If the application generates any other response, that response is returned to the client and the request is ended. The response can be any valid HTTP response, including "Access Denied" or "Redirect".
The Authorizer role is useful for:
Open Market has developed a FastCGI application library that implements the FastCGI protocol (hiding the protocol details from the developer). This library makes implementing FastCGI programs as easy as writing CGI applications.
The application library provides a replacement for the C language standard I/O (stdio) routines, such as printf() and gets(). The library converts references to standard input, standard output, and standard error to the FastCGI protocol. References to other files "fall through" to the underlying operating system standard I/O routines.
This approach has several benefits:
Here's a simple FastCGI application:
#include <fcgi_stdio.h> void main(void) { int count = 0; while(FCGI_Accept() >= 0) { printf("Content-type: text/html\r\n"); printf("\r\n"); printf("Hello world!<br>\r\n"); printf("Request number %d.", count++); } exit(0); }
This application returns a "Hello world" HTML response to the client. It also keeps a counter of the number of times it has been accessed, displaying the value of the counter at each request.
The fcgi_stdio.h header file provides the FastCGI replacement routines for the C standard I/O library. The FCGI_Accept() routine accepts a new request from the Web server.
The application library was designed to make migration of existing CGI programs as simple as possible. Many applications can be converted by adding a loop around the main request processing code and recompiling with the FastCGI application library. FastCGI applications have the following structure, with an initialization section and a request processing loop:
Initialize application;
while(FCGI_Accept() >= 0) {
Process request;
}
To ease migration to FastCGI, executables built with the application library can run as either CGI or FastCGI programs, depending on how they are invoked. The library detects the execution environment and automatically selects FastCGI or regular I/O routines, as appropriate.
After migration, developers can clean up their FastCGI applications for best performance:
Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix platforms are available from Open Market. The interpreters are backward-compatible: They can run standard Tcl and Perl applications.
This section describes the FastCGI support in the following Open Market server products:
For more information about FastCGI support, see the Open Market WebServer Installation and Configuration Guide.
FastCGI applications are configured with the server's configuration file. Configuration has two parts.
First, the server administrator defines an application class. For local applications, the application class specifies the details of running the FastCGI application, such as:
For remote applications, the class configuration information includes the host and TCP port to connect to. The Web server assumes that the FastCGI application has been started on the remote host. If a request comes in and the server can't connect to the FastCGI TCP port, the server logs an error and returns an error page to the client.
The second configuration step is mapping the application class to a role:
To simplify migration for existing CGI programs, the WebServer provides a simple way to install new FastCGI programs without having to reconfigure the server. However, this approach doesn't offer all of the performance benefits of FastCGI application classes.
The WebServer treats any file with the extension .fcg as a FastCGI application. When a request corresponds to such a file, the WebServer creates a new FastCGI process to handle the request, and shuts down the process when the request is complete (just as in CGI). In this mode of operation performance is comparable to CGI. Future versions of the WebServer will improve performance by automatically caching processes and re-using them for subsequent requests.
FastCGI programs can improve performance by caching information in the application process. For applications that require frequent but expensive operations such as validating a username/password in an external database for each request, this technique can significantly improve performance.
To improve the effectiveness of this technique, the WebServer implements session affinity. When session affinity is enabled, the WebServer arranges for all requests in a user session to be handled by the same FastCGI application process. What constitutes a "session" is configurable. The default configuration uses the WebServer's built-in session tracking facility to identify user sessions. However, the server administrator can use any part of the request information for the session affinity mapping: the URL path, the client's hostname, the username, etc.
How fast is FastCGI? The answer depends on the application. This section contains some real FastCGI performance measurements, as well as guidelines for estimating the FastCGI speedup.
We measured the relative performance of CGI, FastCGI, and static files on the Open Market WebServer, using a simple application that generates a fixed number of output bytes. The following table shows the measured request processing time for different request types on a typical platform. The times are measured from the client perspective and include client, server, and application processing time.
|
Static file
|
21ms + 0.19ms per Kbyte
|
|
FastCGI
|
22ms + 0.28ms per Kbyte
|
|
CGI
|
59ms + 0.37ms per Kbyte
|
FastCGI performance is comparable to serving static files, and significantly better than CGI (clearly showing the high overhead for process creation). Real applications have an additional time component: process initialization, which should be added to overall request processing time.
Let's use this data to estimate the speedup from migrating a typical database CGI application to FastCGI. Assume the application takes 50ms to initialize the database connection and generates 5K of output data. Request performance can be computed as follows:
| CGI | 59ms + 50ms + (0.37ms)(5) = 111ms |
| FastCGI | 22ms + (0.28ms)(5) = 23ms |
In this example, FastCGI has a 5x performance advantage over CGI, mostly due to savings from not having to create and initialize new processes for each request.
Today's Web business applications need a platform that's fast, open, maintainable, straightforward, stable, and secure. FastCGI's design meets these requirements, and provides for a logical extension from proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI's benefits without losing their existing investment in CGI applications.
For more information about Open Market and our products, visit our Web site at:http://www.openmarket.com/
For more information about the FastCGI protocol and the developer's kit, and the latest information about FastCGI standardization and support in other Web servers, visit the FastCGI project page at:http://www.openmarket.com/fastcgi/


Findings
The aim of the visualization is to show which are the principal topics in the controversy. It is possible to understand which are the most relevant in the battlefield.
The First Amendment is the most mentioned argument (it is important to remember that the research was conducted on google.com) and Facebook its immediate follower. Otherwise the heaviest categories are services and case studies. Regarding the services category, the most mentioned are Facebook, Twitter and the Huffingtion Post because of their recent policies changes that have led to hot discussions. Facebook, the "transparent" social network, is realising a new social network named "Rooms" allowing anonymous posting. Twitter is on the opposite side of Facebook. The Huffington Post recently decided to delete the possibility to post anonymously. Different directions for different social services.
The case studies category is a big one but it is composed by a lot of not so mentioned case studies. The McIntyre v. Ohio Election Commission is the most relevant (even if it is a 1995 court case) because of it is often mentioned in new court cases.
Technologies are not so important for the research because they are not linked directly to the freedom of speech. The regulations category is, instead, an interesting one. In Usa there are not laws or rules directly regulating anonymity. For that reason the First Amendment of the Constitution of United States is often used in defence of anonymous speech. The second important block according to the amount of articles mentioning it is the "Real name verification law". This is a law introduced in China and Korea against anonymity in avoidance of the freedom of speech.
This visualization is an important tool to understand the structure of the controversy and the actors playing in it.


About me
Hello my name is Peter Wachira an aspiring Developer
My passion for coding started during my highschool years
I explored this enriching subject undependently.
I was entraced by the intricacies of coding and its hidden potentials
much seemingly dead information can be braught back to life.
Some projects i have worked on
Reunite Website To reunite lost missing people with their families
Sophies ConfectioneryConfectionery Advertising website


{% extends "layout.html" %} {% block page_title %} Money Claims Prototype {% endblock %} {% block proposition_header %} {% include "includes/propositional_navigation.html" %} {% endblock %} {% block content %} {% include "includes/phase_banner_beta.html" %} Back Is there a reason you can’t be in the same room as the {% if data['party'] == 'claimant' %}defendant{% else %}claimant{% endif %}? Yes Briefly explain why No {% include 'prototypes/prototype-jan-2019/includes/contact.html' %} {% endblock %}


{% autoescape true %}
Towers' Event Hosting Web Page
Choose an event:
-
{% for event in events %}
{{event.name}}
{% endfor %}
Event Capacity: 0
Suscribed Guests: 0
Name:
Surname:
E-Mail:
Company:
E-Mail:
{% endautoescape %}


We aggregate networks!
- target integrated metrics
- cultivate open-source bandwidth
- optimize scalable initiatives
- extend virtual vortals
- deliver viral infrastructures
- disintermediate dynamic e-business
- extend next-generation vortals
- implement global action-items
- engineer collaborative interfaces
- empower one-to-one vortals
- whiteboard end-to-end communities


Running Infrastructure- and Researchprojects
BMBF MIMO - PSSS
Modern radio technology in buildings
Standards in radio technology like Bluetooth or WLAN are most common techniques in households and industry. Countless technical devices (for example telephones, headsets, video displays, ...) use modern radio systems to transmit data wireless.
The spectrum of potential uses is very big so it is conceivable that radio technology and wireless sensor-/actor networks will be stronger supported in fields like:
- automation of buildings
- industrial supervision and controlling functions
- medicine and geriatric monitoring
- entertainment electronics
- safety engineering
- transmitting of data of electronic domestic supply meters
Together with partners in industry the FHTW developed the transmitting method Parallel Sequence Spread Spectrum (PSSS) over short distances as part of a BMBF project. Since 2005 the transmitting method PSSS is part of the international standard IEEE 802.15.4.
The bullet points of current developments at the FHTW are solving problems of interferences in transmitting, transmitting of higher data rates and multipath propagation.
Prototype of a transceiver module consisting of a FPGA-experimental board and a high-frequency part developed in the FHTW
Developments at the FHTW
Modern semi-conductor technology, digital design methods and new theories in transmitting data effort a progression in digitalisation of receiving technology. Further that it provides the spread of cheap and flexible radio technologies.
The main focus of development at the FHTW are MIMO (multiple antenna systems - multiple input multiple output) and channel equalisation for radio technology for short distances in buildings (encouraged by BMBF-AIF) as physical layer.
To reduce the costs for hardware and reduce the absorption of energy the FHTW develops transceiving elements for single carrier systems.
Therefore digital senders and receivers with digital synchronisation in FPGAs (Field Programmable Logic Array) and methods of model-based-design are implemented.
Attended to that there is a reseach for:
- syncronisation methods for layers, symbols and data packages
- modulation and spreading methods
- sensornets
- multisystem applivcations
- room multiplex
Measuring station with programmable sender and receiver - all interesting radio methods can be implemented
Bit error rate for MIMO-PSSS with channel equalisation at a maximum dispersion of 5 symbols
download the complete article [ca. 1.8 Mb]


--- layout: example.html title: Sprites Example shortdesc: Demonstrate how to use sprites on a map. docs: >


Due to legal reasons, we are required to have a terms of service. Here it is:
Last updated: July 22, 2019
Please read these Terms of Service ("Terms", "Terms of Service") carefully before using the https://cavoke.alexkovrigin.me website (the "Service") operated by Cavoke ("us", "we", or "our").
Your access to and use of the Service is conditioned on your acceptance of and compliance with these Terms. These Terms apply to all visitors, users and others who access or use the Service.
By accessing or using the Service you agree to be bound by these Terms. If you disagree with any part of the terms then you may not access the Service. The Terms of Service agreement for Cavoke has been created with the help of TermsFeed.
When you create an account with us, you must provide us information that is accurate, complete, and current at all times. Failure to do so constitutes a breach of the Terms, which may result in immediate termination of your account on our Service.
You are responsible for safeguarding the password that you use to access the Service and for any activities or actions under your password, whether your password is with our Service or a third-party service.
You agree not to disclose your password to any third party. You must notify us immediately upon becoming aware of any breach of security or unauthorized use of your account.
Our Service may contain links to third-party web sites or services that are not owned or controlled by Cavoke.
Cavoke has no control over, and assumes no responsibility for, the content, privacy policies, or practices of any third party web sites or services. You further acknowledge and agree that Cavoke shall not be responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any such content, goods or services available on or through any such web sites or services.
We strongly advise you to read the terms and conditions and privacy policies of any third-party web sites or services that you visit.
We may terminate or suspend access to our Service immediately, without prior notice or liability, for any reason whatsoever, including without limitation if you breach the Terms.
All provisions of the Terms which by their nature should survive termination shall survive termination, including, without limitation, ownership provisions, warranty disclaimers, indemnity and limitations of liability.
We may terminate or suspend your account immediately, without prior notice or liability, for any reason whatsoever, including without limitation if you breach the Terms.
Upon termination, your right to use the Service will immediately cease. If you wish to terminate your account, you may simply discontinue using the Service.
All provisions of the Terms which by their nature should survive termination shall survive termination, including, without limitation, ownership provisions, warranty disclaimers, indemnity and limitations of liability.
These Terms shall be governed and construed in accordance with the laws of Russian Federation, without regard to its conflict of law provisions.
Our failure to enforce any right or provision of these Terms will not be considered a waiver of those rights. If any provision of these Terms is held to be invalid or unenforceable by a court, the remaining provisions of these Terms will remain in effect. These Terms constitute the entire agreement between us regarding our Service, and supersede and replace any prior agreements we might have between us regarding the Service.
We reserve the right, at our sole discretion, to modify or replace these Terms at any time. If a revision is material we will try to provide at least 30 days notice prior to any new terms taking effect. What constitutes a material change will be determined at our sole discretion.
By continuing to access or use our Service after those revisions become effective, you agree to be bound by the revised terms. If you do not agree to the new terms, please stop using the Service.
If you have any questions about these Terms, please contact us.
See also: license and privacy policy


Aakash Verma
Convener
+919740496828
<EMAIL_ADDRESS>Rumy Sinha
Convener
+919740578188
Get In Touch With Us
Hear Me Out


Optus is an octopus. An octopus has a skull and 8 long tentacles. It has no skeleton and is soft. Optus has spots on his skin. Optus is on the hunt for crabs and clams. He spots a crab sitting still in the sand. He attacks the crab and grabs it in his tentacles. But his tentacles get in a tangle. The crab scuttles off. Optus is glum. Optus sulks until he spots a clam. He sets off on the hunt. He grabs the clam, and gobbles up the soft bits. A clam is top grub for an octopus.
in-context


!= include('page-home'); ?>
!= include('page-apikey'); ?>
!= include('page-reports'); ?>
!= include('page-tools'); ?>
!= include('tool-provision-client'); ?>
!= include('tool-claim-order'); ?>
!= include('tool-configure-ssid'); ?>
!= include('tool-configure-vlan'); ?>
!= include('nav-orgnet'); ?>
!= include('nav-menu'); ?>
!= include('store'); ?>


| | |
- gdata.client.GDClient(atom.client.AtomPubClient)
-
- DocsClient
- gdata.client.Query(__builtin__.object)
-
- DocsQuery
class DocsClient(gdata.client.GDClient) |
| |
Client for all features of the Google Documents List API. |
| |
- Method resolution order:
- DocsClient
- gdata.client.GDClient
- atom.client.AtomPubClient
- __builtin__.object
Methods defined here:
- AddAclEntry = add_acl_entry(self, resource, acl_entry, send_notifications=None, **kwargs)
- BatchProcessAclEntries = batch_process_acl_entries(self, resource, entries, **kwargs)
- CopyResource = copy_resource(self, entry, title, **kwargs)
- CreateArchive = create_archive(self, entry, **kwargs)
- CreateResource = create_resource(self, entry, media=None, collection=None, create_uri=None, **kwargs)
- DeleteAclEntry = delete_acl_entry(self, entry, **kwargs)
- DeleteArchive = delete_archive(self, entry, **kwargs)
- DeleteResource = delete_resource(self, entry, permanent=False, **kwargs)
- DeleteRevision = delete_revision(self, entry, **kwargs)
- DownloadArchive = download_resource(self, entry, file_path, extra_params=None, **kwargs)
- DownloadArchiveToMemory = download_resource_to_memory(self, entry, extra_params=None, **kwargs)
- DownloadResource = download_resource(self, entry, file_path, extra_params=None, **kwargs)
- DownloadResourceToMemory = download_resource_to_memory(self, entry, extra_params=None, **kwargs)
- DownloadRevision = download_revision(self, entry, file_path, extra_params=None, **kwargs)
- DownloadRevisionToMemory = download_revision_to_memory(self, entry, extra_params=None, **kwargs)
- GetAcl = get_acl(self, entry, **kwargs)
- GetAclEntry = get_acl_entry(self, entry, **kwargs)
- GetAclEntryBySelfLink = get_acl_entry_by_self_link(self, self_link, **kwargs)
- GetAllResources = get_all_resources(self, uri=None, show_root=None, **kwargs)
- GetArchive = get_archive(self, entry, **kwargs)
- GetArchiveBySelfLink = get_archive_by_self_link(self, self_link, **kwargs)
- GetChanges = get_changes(self, changestamp=None, max_results=None, show_root=None, **kwargs)
- GetMetadata = get_metadata(self, **kwargs)
- GetResource = get_resource(self, entry, **kwargs)
- GetResourceAcl = get_resource_acl(self, entry, **kwargs)
- GetResourceById = get_resource_by_id(self, resource_id, **kwargs)
- GetResourceBySelfLink = get_resource_by_self_link(self, uri, etag=None, show_root=None, **kwargs)
- GetResources = get_resources(self, uri=None, limit=None, show_root=None, **kwargs)
- GetRevision = get_revision(self, entry, **kwargs)
- GetRevisionBySelfLink = get_revision_by_self_link(self, self_link, **kwargs)
- GetRevisions = get_revisions(self, entry, **kwargs)
- MoveResource = move_resource(self, entry, collection=None, keep_in_collections=False, **kwargs)
- PublishRevision = publish_revision(self, entry, publish_auto=None, publish_outside_domain=False, **kwargs)
- Request = request(self, method=None, uri=None, **kwargs)
- UnpublishRevision = unpublish_revision(self, entry, **kwargs)
- UpdateAclEntry = update_acl_entry(self, entry, send_notifications=None, **kwargs)
- UpdateArchive = update_archive(self, entry, **kwargs)
- UpdateResource = update_resource(self, entry, media=None, update_metadata=True, new_revision=False, **kwargs)
- add_acl_entry(self, resource, acl_entry, send_notifications=None, **kwargs)
- Adds the given AclEntry to the given Resource.
Args:
resource: gdata.docs.data.Resource to which to add AclEntry.
acl_entry: gdata.docs.data.AclEntry representing ACL entry to add.
send_notifications: True if users should be notified by email when
this AclEntry is added.
kwargs: Other parameters to pass to post().
Returns:
gdata.docs.data.AclEntry containing information about new entry.
Raises:
ValueError: If given resource has no ACL link.
- batch_process_acl_entries(self, resource, entries, **kwargs)
- Applies the specified operation of each entry in a single request.
To use this, simply set acl_entry.batch_operation to one of
['query', 'insert', 'update', 'delete'], and optionally set
acl_entry.batch_id to a string of your choice.
Then, put all of your modified AclEntry objects into a list and pass
that list as the entries parameter.
Args:
resource: gdata.docs.data.Resource to which the given entries belong.
entries: [gdata.docs.data.AclEntry] to modify in some way.
kwargs: Other args to pass to gdata.client.GDClient.post()
Returns:
Resulting gdata.docs.data.AclFeed of changes.
- copy_resource(self, entry, title, **kwargs)
- Copies the given entry to a new entry with the given title.
Note: Files do not support this feature.
Args:
entry: gdata.docs.data.Resource to copy.
title: String title for the new entry.
kwargs: Other parameters to pass to post().
Returns:
gdata.docs.data.Resource representing duplicated resource.
- create_archive(self, entry, **kwargs)
- Creates a new archive of resources.
Args:
entry: gdata.docs.data.Archive representing metadata of archive to
create.
kwargs: Other parameters to pass to post().
Returns:
gdata.docs.data.Archive containing information about new archive.
- create_resource(self, entry, media=None, collection=None, create_uri=None, **kwargs)
- Creates new entries in Google Docs, and uploads their contents.
Args:
entry: gdata.docs.data.Resource representing initial version
of entry being created. If media is also provided, the entry will
first be created with the given metadata and content.
media: (optional) gdata.data.MediaSource containing the file to be
uploaded.
collection: (optional) gdata.docs.data.Resource representing a collection
in which this new entry should be created. If provided along
with create_uri, create_uri will win (e.g. entry will be created at
create_uri, not necessarily in given collection).
create_uri: (optional) String URI at which to create the given entry. If
collection, media and create_uri are None, use
gdata.docs.client.RESOURCE_FEED_URI. If collection and create_uri are
None, use gdata.docs.client.RESOURCE_UPLOAD_URI. If collection and
media are not None,
collection.GetResumableCreateMediaLink() is used,
with the collection's resource ID substituted in.
kwargs: Other parameters to pass to post() and update().
Returns:
gdata.docs.data.Resource containing information about new entry.
- delete_acl_entry(self, entry, **kwargs)
- Deletes the given AclEntry.
Args:
entry: gdata.docs.data.AclEntry to delete.
kwargs: Other args to pass to gdata.client.GDClient.Delete()
Returns:
Result of delete request.
- delete_archive(self, entry, **kwargs)
- Aborts the given Archive operation, or deletes the Archive.
Args:
entry: gdata.docs.data.Archive to delete.
kwargs: Other args to pass to gdata.client.GDClient.Delete()
Returns:
Result of delete request.
- delete_resource(self, entry, permanent=False, **kwargs)
- Trashes or deletes the given entry.
Args:
entry: gdata.docs.data.Resource to trash or delete.
permanent: True to skip the trash and delete the entry forever.
kwargs: Other args to pass to gdata.client.GDClient.Delete()
Returns:
Result of delete request.
- delete_revision(self, entry, **kwargs)
- Deletes the given Revision.
Args:
entry: gdata.docs.data.Revision to delete.
kwargs: Other args to pass to gdata.client.GDClient.Delete()
Returns:
Result of delete request.
- download_archive = download_resource(self, entry, file_path, extra_params=None, **kwargs)
- download_archive_to_memory = download_resource_to_memory(self, entry, extra_params=None, **kwargs)
- download_resource(self, entry, file_path, extra_params=None, **kwargs)
- Downloads the contents of the given entry to disk.
Note: to download a file in memory, use the DownloadResourceToMemory()
method.
Args:
entry: gdata.docs.data.Resource whose contents to fetch.
file_path: str Full path to which to save file.
extra_params: dict (optional) A map of any further parameters to control
how the document is downloaded/exported. For example, exporting a
spreadsheet as a .csv: extra_params={'gid': 0, 'exportFormat': 'csv'}
kwargs: Other parameters to pass to _download_file().
Raises:
gdata.client.RequestError if the download URL is malformed or the server's
response was not successful.
- download_resource_to_memory(self, entry, extra_params=None, **kwargs)
- Returns the contents of the given entry.
Args:
entry: gdata.docs.data.Resource whose contents to fetch.
extra_params: dict (optional) A map of any further parameters to control
how the document is downloaded/exported. For example, exporting a
spreadsheet as a .csv: extra_params={'gid': 0, 'exportFormat': 'csv'}
kwargs: Other parameters to pass to _get_content().
Returns:
Content of given resource after being downloaded.
Raises:
gdata.client.RequestError if the download URL is malformed or the server's
response was not successful.
- download_revision(self, entry, file_path, extra_params=None, **kwargs)
- Downloads the contents of the given revision to disk.
Note: to download a revision in memory, use the DownloadRevisionToMemory()
method.
Args:
entry: gdata.docs.data.Revision whose contents to fetch.
file_path: str Full path to which to save file.
extra_params: dict (optional) A map of any further parameters to control
how the document is downloaded.
kwargs: Other parameters to pass to _download_file().
Raises:
gdata.client.RequestError if the download URL is malformed or the server's
response was not successful.
- download_revision_to_memory(self, entry, extra_params=None, **kwargs)
- Returns the contents of the given revision.
Args:
entry: gdata.docs.data.Revision whose contents to fetch.
extra_params: dict (optional) A map of any further parameters to control
how the document is downloaded/exported.
kwargs: Other parameters to pass to _get_content().
Returns:
Content of given revision after being downloaded.
Raises:
gdata.client.RequestError if the download URL is malformed or the server's
response was not successful.
- get_acl(self, entry, **kwargs)
- Retrieves an AclFeed for the given resource.
Args:
entry: gdata.docs.data.Resource to fetch AclFeed for.
kwargs: Other args to pass to GetFeed().
Returns:
gdata.docs.data.AclFeed representing retrieved entries.
- get_acl_entry(self, entry, **kwargs)
- Retrieves an AclEntry again.
This is useful if you need to poll for an ACL changing.
Args:
entry: gdata.docs.data.AclEntry to fetch and return.
kwargs: Other args to pass to GetAclEntryBySelfLink().
Returns:
gdata.docs.data.AclEntry representing retrieved entry.
- get_acl_entry_by_self_link(self, self_link, **kwargs)
- Retrieves a particular AclEntry by its self link.
Args:
self_link: URI at which to query for given ACL entry. This can be found
using entry.GetSelfLink().
kwargs: Other parameters to pass to get_entry().
Returns:
gdata.docs.data.AclEntry representing the retrieved entry.
- get_all_resources(self, uri=None, show_root=None, **kwargs)
- Retrieves all of a user's non-collections or everything at the given URI.
Folders are not included in this by default. Pass in a custom URI to
include collections in your query. The DocsQuery class is an easy way to
generate such a URI.
This method makes multiple HTTP requests (by following the feed's next
links) in order to fetch the user's entire document list.
Args:
uri: (optional) URI to query the doclist feed with. If None, then use
DocsClient.RESOURCE_FEED_URI, which will retrieve all
non-collections.
show_root: (optional) True to include indications if a resource is in
the root collection.
kwargs: Other parameters to pass to GetResources().
Returns:
List of gdata.docs.data.Resource objects representing the retrieved
entries.
- get_archive(self, entry, **kwargs)
- Retrieves an archive again given its entry.
This is useful if you need to poll for an archive completing.
Args:
entry: gdata.docs.data.Archive to fetch and return.
kwargs: Other args to pass to GetArchiveBySelfLink().
Returns:
gdata.docs.data.Archive representing retrieved archive.
- get_archive_by_self_link(self, self_link, **kwargs)
- Retrieves a particular archive by its self link.
Args:
self_link: URI at which to query for given archive. This can be found
using entry.GetSelfLink().
kwargs: Other parameters to pass to get_entry().
Returns:
gdata.docs.data.Archive representing the retrieved archive.
- get_changes(self, changestamp=None, max_results=None, show_root=None, **kwargs)
- Retrieves changes to a user's documents list.
Args:
changestamp: (optional) String changestamp value to query since.
If provided, returned changes will have a changestamp larger than
the given one.
max_results: (optional) Number of results to fetch. API will limit
this number to 100 at most.
show_root: (optional) True to include indications if a resource is in
the root collection.
kwargs: Other parameters to pass to get_feed().
Returns:
gdata.docs.data.ChangeFeed.
- get_metadata(self, **kwargs)
- Retrieves the metadata of a user account.
Args:
kwargs: Other parameters to pass to get_entry().
Returns:
gdata.docs.data.Metadata representing metadata of user's account.
- get_resource(self, entry, **kwargs)
- Retrieves a resource again given its entry.
Args:
entry: gdata.docs.data.Resource to fetch and return.
kwargs: Other args to pass to GetResourceBySelfLink().
Returns:
gdata.docs.data.Resource representing retrieved resource.
- get_resource_acl(self, entry, **kwargs)
- Retrieves the ACL sharing permissions for the given entry.
Args:
entry: gdata.docs.data.Resource for which to get ACL.
kwargs: Other parameters to pass to get_feed().
Returns:
gdata.docs.data.AclFeed representing the resource's ACL.
- get_resource_by_id(self, resource_id, **kwargs)
- Retrieves a resource again given its resource ID.
Args:
resource_id: Typed or untyped resource ID of a resource.
kwargs: Other args to pass to GetResourceBySelfLink().
Returns:
gdata.docs.data.Resource representing retrieved resource.
- get_resource_by_self_link(self, uri, etag=None, show_root=None, **kwargs)
- Retrieves a particular resource by its self link.
Args:
uri: str URI at which to query for given resource. This can be found
using entry.GetSelfLink().
etag: str (optional) The document/item's etag value to be used in a
conditional GET. See http://code.google.com/apis/documents/docs/3.0/
developers_guide_protocol.html#RetrievingCached.
show_root: (optional) True to include indications if a resource is in
the root collection.
kwargs: Other parameters to pass to get_entry().
Returns:
gdata.docs.data.Resource representing the retrieved resource.
- get_resources(self, uri=None, limit=None, show_root=None, **kwargs)
- Retrieves the resources in a user's docslist, or the given URI.
Args:
uri: (optional) URI to query for resources. If None, then
gdata.docs.client.DocsClient.RESOURCE_FEED_URI is used, which will
query for all non-collections.
limit: int (optional) A maximum cap for the number of results to
return in the feed. By default, the API returns a maximum of 100
per page. Thus, if you set limit=5000, you will get <= 5000
documents (guarenteed no more than 5000), and will need to follow the
feed's next links (feed.GetNextLink()) to the rest. See
get_everything(). Similarly, if you set limit=50, only <= 50
documents are returned. Note: if the max-results parameter is set in
the uri parameter, it is chosen over a value set for limit.
show_root: (optional) True to include indications if a resource is in
the root collection.
kwargs: Other parameters to pass to get_feed().
Returns:
gdata.docs.data.ResourceFeed feed.
- get_revision(self, entry, **kwargs)
- Retrieves a revision again given its entry.
Args:
entry: gdata.docs.data.Revision to fetch and return.
kwargs: Other args to pass to GetRevisionBySelfLink().
Returns:
gdata.docs.data.Revision representing retrieved revision.
- get_revision_by_self_link(self, self_link, **kwargs)
- Retrieves a particular reivision by its self link.
Args:
self_link: URI at which to query for given revision. This can be found
using entry.GetSelfLink().
kwargs: Other parameters to pass to get_entry().
Returns:
gdata.docs.data.Revision representing the retrieved revision.
- get_revisions(self, entry, **kwargs)
- Retrieves the revision history for a resource.
Args:
entry: gdata.docs.data.Resource for which to get revisions.
kwargs: Other parameters to pass to get_feed().
Returns:
gdata.docs.data.RevisionFeed representing the resource's revisions.
- move_resource(self, entry, collection=None, keep_in_collections=False, **kwargs)
- Moves an item into a different collection (or out of all collections).
Args:
entry: gdata.docs.data.Resource to move.
collection: gdata.docs.data.Resource (optional) An object representing
the destination collection. If None, set keep_in_collections to
False to remove the item from all collections.
keep_in_collections: boolean (optional) If True, the given entry
is not removed from any existing collections it is already in.
kwargs: Other parameters to pass to post().
Returns:
gdata.docs.data.Resource of the moved entry.
- publish_revision(self, entry, publish_auto=None, publish_outside_domain=False, **kwargs)
- Publishes the given revision.
This method can only be used for document revisions.
Args:
entry: Revision to update.
publish_auto: True to automatically publish future revisions of the
document. False to not automatically publish future revisions.
None to take no action and use the default value.
publish_outside_domain: True to make the published revision available
outside of a Google Apps domain. False to not publish outside
the domain. None to use the default value.
kwargs: Other parameters to pass to super(DocsClient, self).update().
Returns:
gdata.docs.data.Revision representing the updated revision.
- request(self, method=None, uri=None, **kwargs)
- Add support for imitating other users via 2-Legged OAuth.
Args:
uri: (optional) URI of the request in which to replace default with
self.xoauth_requestor_id.
Returns:
Result of super(DocsClient, self).request().
- unpublish_revision(self, entry, **kwargs)
- Unpublishes the given revision.
This method can only be used for document revisions.
Args:
entry: Revision to update.
kwargs: Other parameters to pass to super(DocsClient, self).update().
Returns:
gdata.docs.data.Revision representing the updated revision.
- update_acl_entry(self, entry, send_notifications=None, **kwargs)
- Updates the given AclEntry with new metadata.
Args:
entry: AclEntry to update. Make any metadata changes to this entry.
send_notifications: True if users should be notified by email when
this AclEntry is updated.
kwargs: Other parameters to pass to super(DocsClient, self).update().
Returns:
gdata.docs.data.AclEntry representing the updated ACL entry.
- update_archive(self, entry, **kwargs)
- Updates the given Archive with new metadata.
This method is really only useful for updating the notification email
address of an archive that is being processed.
Args:
entry: Archive to update. Make any metadata changes to this entry.
kwargs: Other parameters to pass to super(DocsClient, self).update().
Returns:
gdata.docs.data.Archive representing the updated archive.
- update_resource(self, entry, media=None, update_metadata=True, new_revision=False, **kwargs)
- Updates an entry in Google Docs with new metadata and/or new data.
Args:
entry: Entry to update. Make any metadata changes to this entry.
media: (optional) gdata.data.MediaSource object containing the file with
which to replace the entry's data.
update_metadata: (optional) True to update the metadata from the entry
itself. You might set this to False to only update an entry's
file content, and not its metadata.
new_revision: (optional) True to create a new revision with this update,
False otherwise.
kwargs: Other parameters to pass to post().
Returns:
gdata.docs.data.Resource representing the updated entry.
Data and other attributes defined here:
- alt_auth_service = 'wise'
- alt_auth_token = None
- api_version = '3.0'
- auth_scopes = ('https://docs.google.com/feeds/', 'https://spreadsheets.google.com/feeds/', 'https://docs.googleusercontent.com/')
- auth_service = 'writely'
- host = 'docs.google.com'
- ssl = True
Methods inherited from gdata.client.GDClient:
- Batch = batch(self, feed, uri=None, force=False, auth_token=None, **kwargs)
- Sends a batch request to the server to execute operation entries.
Args:
feed: A batch feed containing batch entries, each is an operation.
uri: (optional) The uri to which the batch request feed should be POSTed.
If none is provided, then the feed's edit link will be used.
force: (optional) boolean set to True if you want the batch update to
clobber all data. If False, the version in the information in the
feed object will cause the server to check to see that no changes
intervened between when you fetched the data and when you sent the
changes.
auth_token: (optional) An object which sets the Authorization HTTP header
in its modify_request method. Recommended classes include
gdata.gauth.ClientLoginToken and gdata.gauth.AuthSubToken
among others.
- ClientLogin = client_login(self, email, password, source, service=None, account_type='HOSTED_OR_GOOGLE', auth_url=<atom.http_core.Uri object>, captcha_token=None, captcha_response=None)
- Performs an auth request using the user's email address and password.
In order to modify user specific data and read user private data, your
application must be authorized by the user. One way to demonstrage
authorization is by including a Client Login token in the Authorization
HTTP header of all requests. This method requests the Client Login token
by sending the user's email address, password, the name of the
application, and the service code for the service which will be accessed
by the application. If the username and password are correct, the server
will respond with the client login code and a new ClientLoginToken
object will be set in the client's auth_token member. With the auth_token
set, future requests from this client will include the Client Login
token.
For a list of service names, see
http://code.google.com/apis/gdata/faq.html#clientlogin
For more information on Client Login, see:
http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html
Args:
email: str The user's email address or username.
password: str The password for the user's account.
source: str The name of your application. This can be anything you
like but should should give some indication of which app is
making the request.
service: str The service code for the service you would like to access.
For example, 'cp' for contacts, 'cl' for calendar. For a full
list see
http://code.google.com/apis/gdata/faq.html#clientlogin
If you are using a subclass of the gdata.client.GDClient, the
service will usually be filled in for you so you do not need
to specify it. For example see BloggerClient,
SpreadsheetsClient, etc.
account_type: str (optional) The type of account which is being
authenticated. This can be either 'GOOGLE' for a Google
Account, 'HOSTED' for a Google Apps Account, or the
default 'HOSTED_OR_GOOGLE' which will select the Google
Apps Account if the same email address is used for both
a Google Account and a Google Apps Account.
auth_url: str (optional) The URL to which the login request should be
sent.
captcha_token: str (optional) If a previous login attempt was reponded
to with a CAPTCHA challenge, this is the token which
identifies the challenge (from the CAPTCHA's URL).
captcha_response: str (optional) If a previous login attempt was
reponded to with a CAPTCHA challenge, this is the
response text which was contained in the challenge.
Returns:
Generated token, which is also stored in this object.
Raises:
A RequestError or one of its suclasses: BadAuthentication,
BadAuthenticationServiceURL, ClientLoginFailed,
ClientLoginTokenMissing, or CaptchaChallenge
- Delete = delete(self, entry_or_uri, auth_token=None, force=False, **kwargs)
- GetAccessToken = get_access_token(self, request_token, url='https://www.google.com/accounts/OAuthGetAccessToken')
- Exchanges an authorized OAuth request token for an access token.
Contacts the Google OAuth server to upgrade a previously authorized
request token. Once the request token is upgraded to an access token,
the access token may be used to access the user's data.
For more details, see the Google Accounts OAuth documentation:
http://code.google.com/apis/accounts/docs/OAuth.html#AccessToken
Args:
request_token: An OAuth token which has been authorized by the user.
url: (optional) The URL to which the upgrade request should be sent.
Defaults to: https://www.google.com/accounts/OAuthAuthorizeToken
- GetEntry = get_entry(self, uri, auth_token=None, converter=None, desired_class=<class 'gdata.data.GDEntry'>, etag=None, **kwargs)
- GetFeed = get_feed(self, uri, auth_token=None, converter=None, desired_class=<class 'gdata.data.GDFeed'>, **kwargs)
- GetNext = get_next(self, feed, auth_token=None, converter=None, desired_class=None, **kwargs)
- Fetches the next set of results from the feed.
When requesting a feed, the number of entries returned is capped at a
service specific default limit (often 25 entries). You can specify your
own entry-count cap using the max-results URL query parameter. If there
are more results than could fit under max-results, the feed will contain
a next link. This method performs a GET against this next results URL.
Returns:
A new feed object containing the next set of entries in this feed.
- GetOAuthToken = get_oauth_token(self, scopes, next, consumer_key, consumer_secret=None, rsa_private_key=None, url='https://www.google.com/accounts/OAuthGetRequestToken')
- Obtains an OAuth request token to allow the user to authorize this app.
Once this client has a request token, the user can authorize the request
token by visiting the authorization URL in their browser. After being
redirected back to this app at the 'next' URL, this app can then exchange
the authorized request token for an access token.
For more information see the documentation on Google Accounts with OAuth:
http://code.google.com/apis/accounts/docs/OAuth.html#AuthProcess
Args:
scopes: list of strings or atom.http_core.Uri objects which specify the
URL prefixes which this app will be accessing. For example, to access
the Google Calendar API, you would want to use scopes:
['https://www.google.com/calendar/feeds/',
'http://www.google.com/calendar/feeds/']
next: str or atom.http_core.Uri object, The URL which the user's browser
should be sent to after they authorize access to their data. This
should be a URL in your application which will read the token
information from the URL and upgrade the request token to an access
token.
consumer_key: str This is the identifier for this application which you
should have received when you registered your application with Google
to use OAuth.
consumer_secret: str (optional) The shared secret between your app and
Google which provides evidence that this request is coming from you
application and not another app. If present, this libraries assumes
you want to use an HMAC signature to verify requests. Keep this data
a secret.
rsa_private_key: str (optional) The RSA private key which is used to
generate a digital signature which is checked by Google's server. If
present, this library assumes that you want to use an RSA signature
to verify requests. Keep this data a secret.
url: The URL to which a request for a token should be made. The default
is Google's OAuth request token provider.
- ModifyRequest = modify_request(self, http_request)
- Adds or changes request before making the HTTP request.
This client will add the API version if it is specified.
Subclasses may override this method to add their own request
modifications before the request is made.
- Post = post(self, entry, uri, auth_token=None, converter=None, desired_class=None, **kwargs)
- RequestClientLoginToken = request_client_login_token(self, email, password, source, service=None, account_type='HOSTED_OR_GOOGLE', auth_url=<atom.http_core.Uri object>, captcha_token=None, captcha_response=None)
- RevokeToken = revoke_token(self, token=None, url=<atom.http_core.Uri object>)
- Requests that the token be invalidated.
This method can be used for both AuthSub and OAuth tokens (to invalidate
a ClientLogin token, the user must change their password).
Returns:
True if the server responded with a 200.
Raises:
A RequestError if the server responds with a non-200 status.
- Update = update(self, entry, auth_token=None, force=False, uri=None, **kwargs)
- Edits the entry on the server by sending the XML for this entry.
Performs a PUT and converts the response to a new entry object with a
matching class to the entry passed in.
Args:
entry:
auth_token:
force: boolean stating whether an update should be forced. Defaults to
False. Normally, if a change has been made since the passed in
entry was obtained, the server will not overwrite the entry since
the changes were based on an obsolete version of the entry.
Setting force to True will cause the update to silently
overwrite whatever version is present.
uri: The uri to put to. If provided, this uri is PUT to rather than the
inferred uri from the entry's edit link.
Returns:
A new Entry object of a matching type to the entry which was passed in.
- UpgradeToken = upgrade_token(self, token=None, url=<atom.http_core.Uri object>)
- Asks the Google auth server for a multi-use AuthSub token.
For details on AuthSub, see:
http://code.google.com/apis/accounts/docs/AuthSub.html
Args:
token: gdata.gauth.AuthSubToken or gdata.gauth.SecureAuthSubToken
(optional) If no token is passed in, the client's auth_token member
is used to request the new token. The token object will be modified
to contain the new session token string.
url: str or atom.http_core.Uri (optional) The URL to which the token
upgrade request should be sent. Defaults to:
https://www.google.com/accounts/AuthSubSessionToken
Returns:
The upgraded gdata.gauth.AuthSubToken object.
- batch(self, feed, uri=None, force=False, auth_token=None, **kwargs)
- Sends a batch request to the server to execute operation entries.
Args:
feed: A batch feed containing batch entries, each is an operation.
uri: (optional) The uri to which the batch request feed should be POSTed.
If none is provided, then the feed's edit link will be used.
force: (optional) boolean set to True if you want the batch update to
clobber all data. If False, the version in the information in the
feed object will cause the server to check to see that no changes
intervened between when you fetched the data and when you sent the
changes.
auth_token: (optional) An object which sets the Authorization HTTP header
in its modify_request method. Recommended classes include
gdata.gauth.ClientLoginToken and gdata.gauth.AuthSubToken
among others.
- client_login(self, email, password, source, service=None, account_type='HOSTED_OR_GOOGLE', auth_url=<atom.http_core.Uri object>, captcha_token=None, captcha_response=None)
- Performs an auth request using the user's email address and password.
In order to modify user specific data and read user private data, your
application must be authorized by the user. One way to demonstrage
authorization is by including a Client Login token in the Authorization
HTTP header of all requests. This method requests the Client Login token
by sending the user's email address, password, the name of the
application, and the service code for the service which will be accessed
by the application. If the username and password are correct, the server
will respond with the client login code and a new ClientLoginToken
object will be set in the client's auth_token member. With the auth_token
set, future requests from this client will include the Client Login
token.
For a list of service names, see
http://code.google.com/apis/gdata/faq.html#clientlogin
For more information on Client Login, see:
http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html
Args:
email: str The user's email address or username.
password: str The password for the user's account.
source: str The name of your application. This can be anything you
like but should should give some indication of which app is
making the request.
service: str The service code for the service you would like to access.
For example, 'cp' for contacts, 'cl' for calendar. For a full
list see
http://code.google.com/apis/gdata/faq.html#clientlogin
If you are using a subclass of the gdata.client.GDClient, the
service will usually be filled in for you so you do not need
to specify it. For example see BloggerClient,
SpreadsheetsClient, etc.
account_type: str (optional) The type of account which is being
authenticated. This can be either 'GOOGLE' for a Google
Account, 'HOSTED' for a Google Apps Account, or the
default 'HOSTED_OR_GOOGLE' which will select the Google
Apps Account if the same email address is used for both
a Google Account and a Google Apps Account.
auth_url: str (optional) The URL to which the login request should be
sent.
captcha_token: str (optional) If a previous login attempt was reponded
to with a CAPTCHA challenge, this is the token which
identifies the challenge (from the CAPTCHA's URL).
captcha_response: str (optional) If a previous login attempt was
reponded to with a CAPTCHA challenge, this is the
response text which was contained in the challenge.
Returns:
Generated token, which is also stored in this object.
Raises:
A RequestError or one of its suclasses: BadAuthentication,
BadAuthenticationServiceURL, ClientLoginFailed,
ClientLoginTokenMissing, or CaptchaChallenge
- delete(self, entry_or_uri, auth_token=None, force=False, **kwargs)
- get_access_token(self, request_token, url='https://www.google.com/accounts/OAuthGetAccessToken')
- Exchanges an authorized OAuth request token for an access token.
Contacts the Google OAuth server to upgrade a previously authorized
request token. Once the request token is upgraded to an access token,
the access token may be used to access the user's data.
For more details, see the Google Accounts OAuth documentation:
http://code.google.com/apis/accounts/docs/OAuth.html#AccessToken
Args:
request_token: An OAuth token which has been authorized by the user.
url: (optional) The URL to which the upgrade request should be sent.
Defaults to: https://www.google.com/accounts/OAuthAuthorizeToken
- get_entry(self, uri, auth_token=None, converter=None, desired_class=<class 'gdata.data.GDEntry'>, etag=None, **kwargs)
- get_feed(self, uri, auth_token=None, converter=None, desired_class=<class 'gdata.data.GDFeed'>, **kwargs)
- get_next(self, feed, auth_token=None, converter=None, desired_class=None, **kwargs)
- Fetches the next set of results from the feed.
When requesting a feed, the number of entries returned is capped at a
service specific default limit (often 25 entries). You can specify your
own entry-count cap using the max-results URL query parameter. If there
are more results than could fit under max-results, the feed will contain
a next link. This method performs a GET against this next results URL.
Returns:
A new feed object containing the next set of entries in this feed.
- get_oauth_token(self, scopes, next, consumer_key, consumer_secret=None, rsa_private_key=None, url='https://www.google.com/accounts/OAuthGetRequestToken')
- Obtains an OAuth request token to allow the user to authorize this app.
Once this client has a request token, the user can authorize the request
token by visiting the authorization URL in their browser. After being
redirected back to this app at the 'next' URL, this app can then exchange
the authorized request token for an access token.
For more information see the documentation on Google Accounts with OAuth:
http://code.google.com/apis/accounts/docs/OAuth.html#AuthProcess
Args:
scopes: list of strings or atom.http_core.Uri objects which specify the
URL prefixes which this app will be accessing. For example, to access
the Google Calendar API, you would want to use scopes:
['https://www.google.com/calendar/feeds/',
'http://www.google.com/calendar/feeds/']
next: str or atom.http_core.Uri object, The URL which the user's browser
should be sent to after they authorize access to their data. This
should be a URL in your application which will read the token
information from the URL and upgrade the request token to an access
token.
consumer_key: str This is the identifier for this application which you
should have received when you registered your application with Google
to use OAuth.
consumer_secret: str (optional) The shared secret between your app and
Google which provides evidence that this request is coming from you
application and not another app. If present, this libraries assumes
you want to use an HMAC signature to verify requests. Keep this data
a secret.
rsa_private_key: str (optional) The RSA private key which is used to
generate a digital signature which is checked by Google's server. If
present, this library assumes that you want to use an RSA signature
to verify requests. Keep this data a secret.
url: The URL to which a request for a token should be made. The default
is Google's OAuth request token provider.
- modify_request(self, http_request)
- Adds or changes request before making the HTTP request.
This client will add the API version if it is specified.
Subclasses may override this method to add their own request
modifications before the request is made.
- post(self, entry, uri, auth_token=None, converter=None, desired_class=None, **kwargs)
- request_client_login_token(self, email, password, source, service=None, account_type='HOSTED_OR_GOOGLE', auth_url=<atom.http_core.Uri object>, captcha_token=None, captcha_response=None)
- revoke_token(self, token=None, url=<atom.http_core.Uri object>)
- Requests that the token be invalidated.
This method can be used for both AuthSub and OAuth tokens (to invalidate
a ClientLogin token, the user must change their password).
Returns:
True if the server responded with a 200.
Raises:
A RequestError if the server responds with a non-200 status.
- update(self, entry, auth_token=None, force=False, uri=None, **kwargs)
- Edits the entry on the server by sending the XML for this entry.
Performs a PUT and converts the response to a new entry object with a
matching class to the entry passed in.
Args:
entry:
auth_token:
force: boolean stating whether an update should be forced. Defaults to
False. Normally, if a change has been made since the passed in
entry was obtained, the server will not overwrite the entry since
the changes were based on an obsolete version of the entry.
Setting force to True will cause the update to silently
overwrite whatever version is present.
uri: The uri to put to. If provided, this uri is PUT to rather than the
inferred uri from the entry's edit link.
Returns:
A new Entry object of a matching type to the entry which was passed in.
- upgrade_token(self, token=None, url=<atom.http_core.Uri object>)
- Asks the Google auth server for a multi-use AuthSub token.
For details on AuthSub, see:
http://code.google.com/apis/accounts/docs/AuthSub.html
Args:
token: gdata.gauth.AuthSubToken or gdata.gauth.SecureAuthSubToken
(optional) If no token is passed in, the client's auth_token member
is used to request the new token. The token object will be modified
to contain the new session token string.
url: str or atom.http_core.Uri (optional) The URL to which the token
upgrade request should be sent. Defaults to:
https://www.google.com/accounts/AuthSubSessionToken
Returns:
The upgraded gdata.gauth.AuthSubToken object.
Methods inherited from atom.client.AtomPubClient:
- Get = get(self, uri=None, auth_token=None, http_request=None, **kwargs)
- Performs a request using the GET method, returns an HTTP response.
- Put = put(self, uri=None, data=None, auth_token=None, http_request=None, **kwargs)
- Sends data using the PUT method, returns an HTTP response.
- __init__(self, http_client=None, host=None, auth_token=None, source=None, xoauth_requestor_id=None, **kwargs)
- Creates a new AtomPubClient instance.
Args:
source: The name of your application.
http_client: An object capable of performing HTTP requests through a
request method. This object is used to perform the request
when the AtomPubClient's request method is called. Used to
allow HTTP requests to be directed to a mock server, or use
an alternate library instead of the default of httplib to
make HTTP requests.
host: str The default host name to use if a host is not specified in the
requested URI.
auth_token: An object which sets the HTTP Authorization header when its
modify_request method is called.
- get(self, uri=None, auth_token=None, http_request=None, **kwargs)
- Performs a request using the GET method, returns an HTTP response.
- put(self, uri=None, data=None, auth_token=None, http_request=None, **kwargs)
- Sends data using the PUT method, returns an HTTP response.
Data descriptors inherited from atom.client.AtomPubClient:
- __dict__
- dictionary for instance variables (if defined)
- __weakref__
- list of weak references to the object (if defined)
Data and other attributes inherited from atom.client.AtomPubClient:
- auth_token = None
- xoauth_requestor_id = None
|
class DocsQuery(gdata.client.Query) |
| | |
- Method resolution order:
- DocsQuery
- gdata.client.Query
- __builtin__.object
Methods defined here:
- ModifyRequest = modify_request(self, http_request)
- __init__(self, title=None, title_exact=None, opened_min=None, opened_max=None, edited_min=None, edited_max=None, owner=None, writer=None, reader=None, show_collections=None, show_root=None, show_deleted=None, ocr=None, target_language=None, source_language=None, convert=None, query=None, **kwargs)
- Constructs a query URL for the Google Documents List API.
Args:
title: str (optional) Specifies the search terms for the title of a
document. This parameter used without title_exact will only
submit partial queries, not exact queries.
title_exact: str (optional) Meaningless without title. Possible values
are 'true' and 'false'. Note: Matches are case-insensitive.
opened_min: str (optional) Lower bound on the last time a document was
opened by the current user. Use the RFC 3339 timestamp
format. For example: opened_min='2005-08-09T09:57:00-08:00'.
opened_max: str (optional) Upper bound on the last time a document was
opened by the current user. (See also opened_min.)
edited_min: str (optional) Lower bound on the last time a document was
edited by the current user. This value corresponds to the edited.text
value in the doc's entry object, which represents changes to the
document's content or metadata. Use the RFC 3339 timestamp format.
For example: edited_min='2005-08-09T09:57:00-08:00'
edited_max: str (optional) Upper bound on the last time a document was
edited by the user. (See also edited_min.)
owner: str (optional) Searches for documents with a specific owner. Use
the email address of the owner. For example<EMAIL_ADDRESS>writer: str (optional) Searches for documents which can be written to
by specific users. Use a single email address or a comma separated list
of email addresses. For example: writer='user1<EMAIL_ADDRESS>reader: str (optional) Searches for documents which can be read by
specific users. (See also writer.)
show_collections: str (optional) Specifies whether the query should return
collections as well as documents and files. Possible values are 'true'
and 'false'. Default is 'false'.
show_root: (optional) 'true' to specify when an item is in the root
collection. Default is 'false'
show_deleted: str (optional) Specifies whether the query should return
documents which are in the trash as well as other documents.
Possible values are 'true' and 'false'. Default is false.
ocr: str (optional) Specifies whether to attempt OCR on a .jpg, .png, or
.gif upload. Possible values are 'true' and 'false'. Default is
false. See OCR in the Protocol Guide:
http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html#OCR
target_language: str (optional) Specifies the language to translate a
document into. See Document Translation in the Protocol Guide for a
table of possible values:
http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html#DocumentTranslation
source_language: str (optional) Specifies the source language of the
original document. Optional when using the translation service.
If not provided, Google will attempt to auto-detect the source
language. See Document Translation in the Protocol Guide for a table of
possible values (link in target_language).
convert: str (optional) Used when uploading files specify if document uploads
should convert to a native Google Docs format.
Possible values are 'true' and 'false'. The default is 'true'.
query: str (optional) Full-text query to use. See the 'q' parameter in
the documentation.
- modify_request(self, http_request)
Methods inherited from gdata.client.Query:
- AddCustomParameter = add_custom_parameter(self, key, value)
- add_custom_parameter(self, key, value)
Data descriptors inherited from gdata.client.Query:
- __dict__
- dictionary for instance variables (if defined)
- __weakref__
- list of weak references to the object (if defined)
| |


ha ha ha
This is my test
this is log
THis is second h2
a
163.com
sohu.com
81222.com
local.book
error.local.book2
qttc
Shippng method
first daty
two day
three day
Shippng method
first daty
two day
three day
button
1 day
2 day
3 day
4 day


{if group_id == "1" OR member_id == "{segment_3}"}
We might need some more info before you can edit your profile:
{email_block} {/email_block} {password_block} {/password_block}
{/exp:user:edit}
{/exp:user:edit}
Avatars should be square, and at least 200x200. If you sign in via Twitter, we probably grabbed your avatar from there. You can replace it.
{/exp:user:edit} {if group_id == "1" OR group_id == "6" OR group_id == "7" OR group_id == "10"}
Author photos should be at least 250x250. Our editors may crop and resize if needed.
{/exp:user:edit} {/if} {if:else} {redirect='/authors'} {/if}


Normal Lab Values
- Reference ranges vary per institution and are unique to the device utilized for testing
- -PT 12-14 seconds
- -PTT 24-36 seconds
- -ATIII 82-139% (age dependent)
- -Anti factor Xa 0 u/mL
- -ACT 90-110 seconds
ECLS Lab Values
- Reference ranges vary per institution and are unique to the device utilized for testing
- -PT <15-16 seconds
- -PTT 60-90 seconds
- -ATIII 80-120%
- -Anti factor Xa 0.3-0.8 u/mL
- -ACT 180-220 seconds
Download this information - it is good reference material.
Download this resources
Lab Sampling
- Coags should be collected from a sampling port prior to heparin infusion (if heparin is infusing into the ECLS circuit)
- -Prevents sample contamination
- It is important to wait 3-4 hrs after heparin drip changes or boluses to send coag labs. It is acceptable to send labs prior to this if checking for under anticoagulation, response to apparent over anticoagulation may not be advisable.
- -May not reflect steady state of heparin infusion if drawn prior to the recommended wait time.
Remember to want this critical 3-4 period after heparin drop changes or boluses to send coag labs.
Labs
- Activated Clotting Time (ACT)
- -Bedside/point of care test
- -Measured in seconds
- Several different devices and activators
- Micro clot
- Macro Clot
- Looks at overall coagulation
- (Common and Intrinsic pathways)
- Prothrombin time (PT)
- -Extrinsic pathway
- -Should be normal in presence of heparin
- If not, treat cause
- Normalize with FFP administration
- -Prolonged with dilution and DIC
- -Will be significantly impacted by rFVIIa administration
Remember the Prothrombin time(PT) should be normal in the presence of heparin.
- Activated Partial Thromboplastin Time (PTT)
- -Intrinsic pathway
- -Impacted directly by heparin and direct thrombin inhibitors
- -Correlates with antifactor Xa
- -Also influenced by platelets, fibrinogen, and other clotting factors


F1 Raceweek: Vettel and Leclerc – when team-mates collide
by FSA EditorSebastian Vettel and Charles Leclerc collided in Brazil but they are far from the first team-mates to come together in Formula One.
The margins for error in Formula One are so small that crashes are an inevitability.
But the attention on collisions is exacerbated tenfold when they occur between team-mates, as was the case at the Brazilian Grand Prix this weekend between Ferrari’s Sebastian Vettel and Charles Leclerc.
Fighting it out for fourth place at Interlagos, the pair came together on lap 66 with each driver seeing their respective races ended as a result.
It was an incident that earned the ire of Ferrari team boss Mattia Binotto, who said: “Free to fight doesn’t mean to do silly actions – especially between the two team-mates, between the two Ferraris.
“It was simply a silly action.”
But it was certainly not the first time team-mates have collided on track, and it is probably safe to say will not be the last. We have taken a look at some of the most memorable incidents here:
ALAIN PROST AND AYRTON SENNA, JAPAN, 1989
Arguably the most famous of all team-mate collisions took place at the 1989 Japanese Grand Prix when legendary duo Alain Prost and Ayrton Senna were battling for the title. Trailing Prost in the standings, Senna attempted a daring move up the inside of his McLaren team-mate. Prost held his line and the two collided. Senna managed to get going again but, despite crossing the line first, was later disqualified for cutting a chicane meaning Prost became world champion.
MIKA HAKKINEN AND DAVID COULTHARD, AUSTRIA, 1999
Some 10 years later and again it was McLaren under the microscope. With Ferrari great Michael Schumacher having broken his leg in a huge crash at Silverstone, Mika Hakkinen sought about building a lead in the drivers’ standings. Leading through the first corner from pole of the Austrian Grand Prix, the Finn’s chances of victory were severely dented when David Coulthard clipped his team-mate with a limp attempt to pass. Hakkinen recovered valiantly to third, but Coulthard finished second behind Eddie Irvine.
SEBASTIAN VETTEL AND MARK WEBBER, TURKEY, 2010
Vettel’s incident with Leclerc was not a new experience for the German. Nine years ago in Turkey, Mark Webber was aiming for a third straight win but, while in fuel-saving mode, Vettel drew in his Red Bull team-mate only to veer into the Australian following a misjudgement and seeing his race end in a spin.
LEWIS HAMILTON AND NICO ROSBERG, SPAIN, 2016
From karting buddies growing up to fierce title rivals at Mercedes, Lewis Hamilton and Nico Rosberg engaged in a thrilling tussle during their time as team-mates at the German constructor. A couple of years prior, the pair had made contact in Belgium but round five in Barcelona in 2016 saw the pair involved in a much bigger prang. With Rosberg in the wrong engine mode, Hamilton attempted to pass through a gap the German went to block and both were wiped out of the race.
MAX VERSTAPPEN AND DANIEL RICCIARDO, AZERBAIJAN, 2018
Another Red Bull collision, another Australian involved but this time it was Daniel Ricciardo and Max Verstappen who were the guilty parties. The two were involved in a thrilling battle for a podium place and had already touched wheels before Ricciardo smashed the back of Verstappen’s car when attempting a pass on lap 40. Both men were reprimanded over the incident.


You need to complete a course before you can submit a review on it.
Follow these steps to review courses:
- Log in to the Algorithm Lab.
- In the left navigation bar, click Learning Center > Completed.
- On the Completed Courses page, click the course you want to review.
- Scroll down to the User Reviews section and then click the number of stars you want to give the course in your review.
- Write your review.
- Click Submit Review.
The User Reviews section displays your review.


I got my highschool deploma from The Early Summit Program from Chemeketa Cumminity collage in oregon
I chose to go to epicodus becuse I have been dealing with a medical disorder called auto-immune hepititis. I was diagnosed my freshmen year of collage and had to medicly withdraw. It was one of my hardest times in my life. I was bed riden for almost a year and a half. it took me about two years before I started getting better and back on my feet, but by this time I was already behind. I'm still not what I use to be to this day. However this is why I want to program so badly. It alows my to get cerrers that can be done remotely even when im not feeling well and this need is what led me to Epicodus.