Operating Rules
For use in
the Electronic Procurement Project
Known as the "Multi-State
E-MallTM"
Version 2.0
The Current Version of this Document is Available
at:
http://emall.isa.us/or
_______________________________
COPYRIGHT NOTICE
Copyright © 1999 by the
Commonwealth of Massachusetts. All rights reserved. Permission to
reproduce this document is hereby granted provided that the following
limitations on this right are observed: (1) all copies must clearly indicate
that this work is published by and attributed to the Commonwealth of
Massachusetts, as Policy Authority for the Multi-State EMall; and (2) all copies
must include this notice of copyright.
Table of Contents
A.
Scope
A.1.
General
A.2.
Application of these Operating Rules
A.3.
Open Buying on the Internet
A.4.
Contact Information
B.
Authentication: In General
B.1.
Issuance, Use, Modification and Termination of User Name and
Passwords
B.2. Use
of SSL
B.3.
Use of S/MIME
B.4.
Use of Fax, Telephone, U.S. Mail, Commercial Couriers, and
Unsecured/Unauthenticated E-Mail
C.
Authentication: Certificate Policy
C.1.
Introduction
C.2.
General Provisions
C.3.
Identification and Authentication
C.4.
Operational Requirements
C.5.
Physical, Procedural, and Personnel Security Controls
C.6.
Technical Security Controls
C.7.
Certificate and CRL Profiles
C.8.
Specification Administration
D.
Roles, Functions and Authorization of Participating Parties
D.1.
General Concepts
D.2.
Role: Policy Authority (EMall Team/Principal)
D.3.
Role: Business Administrator (EMall Team/Admin.)
D.4.
Role: Operations Administrator (EMall Team/Admin.)
D.5.
Role: State Partner MOU Signatory (State Partner/Principal)
D.6.
Role: State Coordinator (State Partner/Contact)
D.7.
Role: Shopper (State Partner/User)
D.8.
Role: Operational Approver (State Partner/User)
D.9.
Role: Financial Approver (State Partner/User)
D.10.
Role: Receiver (State Partner/User)
D.11.
Role: Supplier Partner MOU Signatory (Supplier Partner/Principal)
D.12.
Role: Supplier Coordinator (Supplier Partner/Contact)
D.13.
Role: Certificate Manufacturer
D.14.
Role: Solution Providers
E.
Technical Requirements
E.1.
User Personal Computer
E.2.
Supplier Partner
E.3.
Physical Security of Computing and Network Resources
F.
Duties and Obligations of the Parties
F.1.
Creation of Legally Binding Purchases
F.2.
Notice
F.3.
Participation Agreements
F.4.
Confidentiality
F.5.
Intellectual Property
F.6. Alternative
Dispute Resolution
F.7.
Governing Law
A. Scope
A.1
GeneralThe Multi-State Emall pilot (Emall)
is an Extranet procurement Web site, hosted by the Commonwealth of Massachusetts
and available to participating states (known as State Partners in this
document). The Emall web site provides links to qualified Supplier "storefronts"
or catalogs, where state procurement staff (known as authorized State Users) can
browse, shop and create requisitions. Public Key Certificate technology coupled
with user name and password ensure that only authorized State Users can submit
approved OBI Orders to the approved suppliers (known as authorized Supplier
Partners). In addition, casual, non-priviliged Internet users can access
certain public portions of the site, but can not engage in binding transactions
unless they are authorized participants in this pilot and agree to accept these
Operating Rules.
A.2 Application of these Operating RulesThese Operating Rules apply to every participant in the Emall. No party
may play any role or otherwise act as a participant in the Emall without signing
a Participation Agreement. Depending on the role a given party plays (i.e. User,
Supplier, Administrator, etc.) a different Participation Agreement with special
terms may be required.
A.3 Open
Buying on the InternetThe Emall is based
upon the Open Buying on the Internet (OBI) specification. OBI is an emerging
standard that defines the technical requirements for conducting business over
the Internet from buyer to seller. The following definition is copied from the
OBI web site:
The OBI standard is an open, flexible design for
business-to-business Internet commerce solutions. It is intended for the
high-volume, low-dollar transactions that account for 80% of most organizations'
purchasing activities. Version 1.0 of the standard document contains an
architecture, as well as technical specifications and guidelines. OBI is not a
product or a service; it is a freely available standard which any organization
can obtain and use.Information about the
OBI standard is available at the web site http://www.openbuy.org/. Version 1.0 and
Version 1.1 of the OBI technical specifications are available from this
site.
A.4 Contact
InformationThe Policy Authority
promulgating these Operating Rules is the Commonwealth of Massachusetts. A
current version of these Operating Rules and related information is available at
http://emall.isa.us/. Signed Participation
Agreements of each party performing a role under these Operating Rules are on
file with the Policy Authority.
For purposes of business communications, parties performing a
role in the EMall may contact:
Nancy Burke, EMall Project Manager,
Commonwealth of Massachusetts, Operational Services Division
One Ashburton Place, Room 1017
Boston, MA 02108
<EMAIL_ADDRESS>617.720.3187
For questions or comments specifically relating
to these Operating Rules, parties performing a role in the EMall may
contact:
Daniel Greenwood, Deputy General Counsel, Information
Technology Division & EMall Counsel and Steering Committee
Member
Commonwealth of Massachusetts
One Ashburton Place, Room 801
Boston, MA
02108
<EMAIL_ADDRESS>or<EMAIL_ADDRESS>617.973.0071
B. Authentication: In
General
B.1. Issuance, Use, Modification and
Termination of User Name and PasswordsA
User name and Password must be supplied by every User of the EMall Server
accessing a non-public portion of the system. No User may share or otherwise
reveal their Password or other authorized Personal Identification Number
(PIN). Any suspicion that a Password has been compromised must be
immediately communicated to the State Coordinator for that User. A Password may
be re-set in the event that an authorized User forgets the Password. A User
should contact their State Coordinator, who can authorize a password reset from
the Operations Administrator. Upon proper notification by an authorized
State Coordinator under these Operating Rules and relevant implementing
agreements, a User's access to the EMall will be terminated and the respective
User name and Password combination for a terminated User will no longer be
valid.
In addition to transmission of the valid Public Key
Certificate, User identification for access to the EMall server also requires
presentation of a user name that corresponds with the Common Name of the
Subscriber as listed in the Public Key Certificate (and that is unique within
the EMall User profiles) and must be transmitted with the corresponding valid
password or PIN.
B.2. Use of SSLEvery person
accessing any non-public portion of the EMall server must use the Secure Sockets
Layer (SSL) protocol. The SSL protocol will be used to authenticate and secure
certain communications between Supplier servers and the EMall server as well as
to encrypt certain session between the browser of a User and the EMall server
and authenticate the identity of authorized EMall Users. A web session invoking
version 3 of the SSL protocol requires use of a duly issued Public Key
Certificate within the browser of an EMall User. SSL 3 is also required to
authenticate and secure the transmission of a valid OBI Order from the EMall
server to the server of a Supplier.
B.3. Use of S/MIMEA Pilot
Participant who is duly issued a Public Key Certificate for use in the EMall may
use that Public Key Certificate to "sign" e-mail to another participant. In
addition, a Pilot Participant may use the duly issued EMall Public Key
Certificate of another participant to encrypt e-mail using the S/MIME standard,
provided each person uses an interoperable e-mail client. In some cases, as
determined by an EMall Administrator, use of S/MIME may be requested or required
to assure official communications via e-mail are confidential and/or
authenticatable.
B.4. Use of Fax, Telephone, U.S.
Mail, Commercial Couriers, and Unsecured/Unauthenticated E-Mail
B.4.1. GeneralAccess as a User
or Administrator to the EMall server will require a valid User name and Password
as well as a recognized Public Key Certificate. However, many other
communications channels will be used for various other purposes throughout the
term of this pilot. It is recognized that implementation of a production system
will require greater specificity regarding permitted and prohibited methods of
communication and corresponding authentication depending on the purposes of the
communications. It is intended that experience gained through this pilot process
will demonstrate appropriate guidelines. For purposes of the pilot, however, it
is expected that most non-critical communications will occur between pilot
participants via phone and e-mail.
B.4.2. Communication of Agreements and
Related DataCommunication of the
implementing agreements under these Operating Rules and related User designation
and authorization data requires greater specificity. Until and unless otherwise
specified in future versions of these Operating Rules, delivery of all completed
forms, agreements and related data, including all designation of roles and
authorities for Users of the EMall system must be communicated via:
* Fax, U.S. Mail or Commercial Couriers, or
* Upon prior approval by the EMall Business Coordinator,
S/MIME Signed E-Mail, signed by private key corresponding to a validly issued
Public Key Certificate for the EMall pilotUntil and
unless return receipt is received by phone call back or other agreed methods,
sender must consider that such data has not been successfully
transmitted.
B.4.3. Other
CommunicationsUnless otherwise specified
in these Operating Rules, communications may be conducted by any reasonable
means that are appropriate under the circumstances..
C. Authentication: Certificate Policy
C.1.
IntroductionFor purposes of the Multi-State
EMall pilot, a Public Key Certificate (Certificate) is a computer-based record
which:
(a) identifies the entity or brand associated with issuance
of it;
(b) names or identifies the person or device
associated with the corresponding private key;
(c)
contains the public key corresponding to that private key of that person or
device; and
(d) is digitally signed by the
Certificate Manufacturer that creates the Certificate.
In transacting business over the Internet, it is critical that both the
seller and buyer be assured that the transactions exchanged are secure. Public
key encryption coupled with Public Key Certificates can provide part of this
security by ensuring the confidentiality and/or authentication of electronic
business exchanges. When Public Key Certificates are attached to transactions,
parties on each side of a purchase have some evidence of who the message came
from and that it was not tampered with. The EMall pilot uses Certificates to
bolster the authentication provided by the Password and User name in the Emall
system. A Certificate is not, by itself, sufficient to perform any transactions
within the EMall system.
Public Key Certificates are used to authenticate Web servers
and their clients via protocols such as SSL 3.0. A Public Key Certificate is
analogous to an identification card issued by an employer or membership
organization. Each User participating in the EMall pilot must have at least one
Public Key Certificate. Certificates will be issued at no cost by a designated
and contracted party known as a Certificate Manufacturer (CM). The CM will issue
a Certificate to Users who have been identified by their respective State
Coordinators and accepted by the EMall Administrator.
The browser specifications, as noted in the Section E Technical
Requirements, accommodates the use of Public Key Certificates. A technical
resource for each State Partner will be needed to assist each User with
the installation of that User's Certificate. This technical resource
and/or the state coordinator must have an adequate understanding of the
technical and operational requirements and responsibilities associated with
managing, issuing and maintaining Public Key Certificates. The technician
shall not have knowledge of any User's password.
This Certificate Policy section of these Operating Rules
governs creation, delivery and other aspects of the Certificate Manufacturing
process as well as the proper use of Public Key Certificates. This section
follows the format of the Internet Engineering Task Force PKIX Part 4 Framework
(available at http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part4-03.txt)
and is in general accord with the guidance provided by Version 1.0 of the draft
"Guidelines for Constructing Policies Governing the Use of Identity-Based Public
Key Certificates" by the Certificate Authority Ratings and Trust (CARAT) Task
Force of the Internet Council of the National Automated Clearinghouse
Association (NACHA) available at http://internetcouncil.nacha.org/CARAT/)
. Please note that many of the basic business and legal terms surrounding
each party's role within the EMall are properly addressed in other sections of
these Operating Rules and will either supplement or replace information reserved
under IETF PKIX-4 headings (such as "liability" and "financial responsibility"
etc.).
C.2. General
Provisions
C.2.1
Obligations
C.2.1.1
Policy Authority ObligationsThe
Policy Authority pays for most or all of the EMall pilot and has initiated the
effort to create this pilot. The chief obligation of the Policy Authority
is to sponsor and organize the EMall pilot, to set policy, including this
certificate policy, and to assure the smooth and successful operation of the
pilot. The policies are set in a manner that affords input and comment
from State Partners and other Pilot Participants.
C.2.1.2 PKI Service Providers
C.<IP_ADDRESS>
Registrars
The Registrar, is the sole point of contact between the PA and the CM
for purposes of requesting the issuance of certificates. The Registrar is
ordinarily the EMall Business Administrator. However, when necessary, the
EMall Operations Administrator may act as Registrar. The Registrar must
keep records of each application request and valid certificates issued.
Each State Coordinator shall also act as a Local Registrar for purposes of
designating authorized Users and therefore certificate subscribers.
C.<IP_ADDRESS> Operations
Administrators
The Operations Administrator (OA) sets the EMall server to grant access
authorized subscribers based on the unique information in each subscriber's
certificate. The OA is responsible for acquiring and installing
"commercial off the shelf" server certificates on the main EMall server as well
as training and development servers, as needed. In addition, the
Operations Administrator is responsible for installing the CM's root certificate
on each EMall server that will process subscriber certificates and for the
distribution of root certificates to each authorized Supplier that will act as a
Relying Party.
C.<IP_ADDRESS> Certificate
Manufacturers
The Certificate Manufacturer (CM) only has duties and responsibilities
toward the Policy Authority and duly designated Administrators and not directly
toward any other pilot participant, other than as specified in this section of
the Operating Rules or as agreed upon by and between the CM, the PA and each
such other party. The CM shall manufacture Public Key Certificates
according to the certificate profile contained in this Certificate Policy upon
the request of the Registrar. Each such certificate shall reflect
accurately the information contained in the certificate application, including
the Common Name and the State associated with each applicant.
C.2.1.3 End Entities (Parties or Their Devices that
Use or Rely Upon Certificates)
C.<IP_ADDRESS> Subscribers
C.<IP_ADDRESS>.1
Users
Each EMall User (including Shoppers, Approvers and Receivers) shall be
issued a Public Key Certificate upon designation and authorization by their
respective State Coordinator and successfully completing and submitting their
User Agreement. A User's EMall certificate does not represent a generic
identification or authorization credential for use outside the EMall. A
User is obligated to refrain from using their EMall certificate in any
communications with non-EMall Pilot Participants or for non-EMall related
business. A User must provide accurate information in the User Agreement
and related forms and to their respective State Coordinator with respect to
EMall activities. A User must immediately notify their State Coordinator
upon notice or reasonable suspicion that information within their certificate is
no longer accurate, including upon the termination of their employment. A
User must immediately notify their State Coordinator upon notice or reasonable
suspicion that the private key corresponding to their certificate has been
compromised (see User Documentation and User Agreement for more
information). A User must abide by the terms and conditions of their User
Agreement.
C.<IP_ADDRESS>.2 EMall Server Certificate for User
Sessions
The EMall server and such other training or support servers as are
designated by the EMall Operations Administrator shall have installed a valid
Server Certificate. To be valid, under this section, a Server Certificate
must be signed by a CM whose certificate signing key is recognized (without
further customization) by each Browser that is supported for use within the
EMall (see Section E. of these Operating Rules). That means that the
public key that corresponds to the private key used to sign the Server
Certificate must be embedded within each such browser at the time the Browser
software is distributed and requires no further installation of a root
certificate or other prefatory work in order to invoke an SSL session. In
addition, a valid certificate must be used only within the starting and ending
dates designated in the Server Certificate and must be replaced prior to
expiration of said ending date.
C.<IP_ADDRESS>.3 EMall Transaction Server
Certificate for OBI Order
Transmissions
The EMall Server Transaction Certificate shall be a public key
certificate used to initialize an encrypted http session and to identify the
EMall server to authorized Supplier transaction server for the purpose of
sending Valid OBI orders using SSL 3. The Operations Administrator shall
assure that a valid EMall Server Transaction Certificate is installed on the
EMall server and will make sufficient information about the contents of that
certificate known to each authorized Supplier who will act as a Relying Party
upon that certificate.
C.<IP_ADDRESS>.4 Other Pilot
Participants
For purposes of testing, support and other activities approved by the PA
or authorized Administrator, any other EMall Pilot Participant may be issued a
Public Key Certificate. Where an individual other than a User issued a
certificate, that person must first agree to abide by relevant sections of these
Operating Rules and any other terms and conditions deemed appropriate by the PA
or it's authorized Administrator. These additional terms must, at a
minimum, specify the purpose and authorized uses of the certificate within the
EMall pilot.
C.<IP_ADDRESS> Relying Parties
C.<IP_ADDRESS>.1
Administrators
The Operations Administrator must require and accept valid EMall
certificates as part of the initial authentication of authorized Users of the
EMall server. Use of a certificate alone shall not be sufficient proof of
identity for purposes of gaining access to User-only section of the EMall
server, but must be accompanied by the authentication requirements specified in
Part B. of these Operating Rules.
C.<IP_ADDRESS>.2
Suppliers
Suppliers may rely upon valid EMall certificates to identify and
authenticate a subscriber as an authorized Shopper, as that role is defined
under these Operating Rules. Suppliers must rely upon a certificate to
authenticate and secure valid OBI Orders from the EMall server. Suppliers
may rely upon certificates to identify a subscriber via S/MIME signed e-mail,
but may not assume any authorization based solely upon usage of a certificate
used for this purpose. Suppliers may not rely upon EMall certificates for
any other purposes than those specified in these Operating Rules.
C.<IP_ADDRESS>.2.1 Shopper Browser Certificate
Used for Authentication to Supplier Web
Catalog
A Supplier should, but need not utilize a subscriber certificate of a
Shopper for authentication. A Supplier that does not rely upon the
subscriber certificate for authentication directly may rely upon certificate and
other User authentication performed by the EMall server and securely passed on
to the Supplier at the beginning of a web catalog session for purposes of
shopping. A Supplier that uses a subscriber certificate for purposes of
authentication must, at a minimum:
* assure that the certificate was manufactured by the
authorized CM for the EMall, based upon the root certificate distributed by the
Operations Administrator; and
* identify the State of the Shopper from within the
certificate for purposes of assuring the correct contracted items and prices are
displayed and that the correct OBI Order Request information is
transmitted.
C.<IP_ADDRESS>.2.2 EMall Server Transaction
Certificate for OBI Orders Used for Authentication to Supplier
Transaction
Server
The EMall Server Transaction Certificate shall be a public key
certificate used to identify the EMall server to authorized Supplier transaction
server for the purpose of sending Valid OBI orders. All Suppliers must
utilize a secure and authenticated SSL 3 (dual authenticated) session for the
transmission of valid OBI Orders from the EMall server. If the SSL 3
session necessary to commence transmission of an OBI Order to a Supplier
transaction server is invoked without a Public Key Certificate or via a Public
Key Certificate other than that provided for under section C.<IP_ADDRESS>.3 of these
Operating Rules (EMall Server Transaction Certificate), then the resulting
transaction must be regarded as invalid. The risk that an unauthorized OBI
Order could be generated that conforms with the format, content and other
process constraints comprising a valid EMall OBI Order is extremely low, but the
risk does exist. If a Supplier wishes to further minimize this risk, then
the Supplier should configure their transaction server to accept EMall OBI
Orders only from the pre-authorized EMall Server Transaction Certificate, based
upon certificate information provided to the Supplier by the EMall Operations
Administrator under section C.<IP_ADDRESS>.3.
C.<IP_ADDRESS>.3 Pilot
Participants
No Pilot Participant may use their certificate to authenticate
themselves to any person or device outside of the EMall pilot. All Pilot
Participants can use their Public Key Certificates to send signed e-mail to any
other Pilot Participant. In addition, any Pilot Participant may use the
Public Key Certificate of another pilot participant to send encrypted e-mail to
that person. Not all Pilot Participants are necessarily entitled to an
EMall certificates.
C.2.2
Liability
Liability
is not dealt with in the Certificate Policy, rather it is governed by the
underlying business contracts and other relevant business agreements between
parties participating in this pilot. This Certificate Policy exists for
the purpose of further defining and clarifying details of this authentication
method and does not comprise the business relationship between the
parties.
C.2.5
Fees
Certificates are
provided at no cost to Pilot Participants.
C.2.6 Publication and
Repository
The CM
maintains a non-public, web-accessible repository of valid and revoked
certificates. For security purposes no further information on this
repository is available in these Operating Rules. From time to time
the PA or it's designated Administrators may request access to this repository
according to terms and processes as mutually agreed between the PA and the
CM.
C.2.7 Compliance
Audit
No Compliance
Audit is necessary under these Operating Rules. More detailed duties and
obligations between the PA and the CM can be found in the Implementing Contract
between those parties by which the CM is contracted to provide certificate
manufacturing services.
C.2.8
Confidentiality
See
section F.4 of these Operating Rules.
C.2.9 Intellectual Property
Rights
See section
F.5 of these Operating Rules.
C.3. Identification and
Authentication
The process and
practices governing identification and authentication of subcribers are
determined by the EMall Business Administrator, with the knowledge and assent of
the EMall Steering Committee and the agreement of each State Partner
Coordinator. The Business Administrator may customize these processes and
practices to conform to different management and organizational environments
among the various State Partners and other authorized Subscribers.
Material procedures must be documented and available for review by the EMall
Steering Committee and any other party with a business need or legal right of
access to that information. Documented processes and relevant practices
may be changed throughout the pilot, but any material changes must require the
knowledge and consent of the EMall Steering Committee.
C.4.
Operational RequirementsSee Section C.2 of
these Operating Guidelines for relevant Operational Requirements.
C.5. Physical, Procedural, and Personnel Security
ControlsThe CM, PA and relevant
Administrators shall agree upon appropriate physical, procedural and personnel
security controls, as needed.
C.6.
Technical Security ControlsThe CM, PA and
relevant Administrators shall agree upon appropriate technical security
controls, as needed.
C.7.
Certificate and CRL ProfilesNote: Content
redacted from this draft for purpose of maintaining security of sensitive
processes. The syntax and semantics underlying the EMall Certificate
Profile is available, to the extent necessary, upon request from any authorized
Relying Party who needs the information to accept or process Public Key
Certificates and to conform to relevant Risk Management guidelines, as
provided under these Operating Rules and by the Policy Authority.
C.8.
Specification AdministrationThe Policy
Authority is the Specification Administration. Matters such as
publication, notice of change and rights to comment on rules changes are dealt
with throughout these Operating Rules and are not unique or specific to the use
of any one authentication method for this business system. The use of
public key certificates, and the policies related to such use, is part of the
overall business system underlying the EMall pilot. General issues related
to Notice of change of these Operating Rules, including any changes to the
Certificate Policy sections of these Operating Rules, can be found in Section
F.2.
D. Roles, Functions and
Authorization of Participating Parties
D.1. General
ConceptsParty: A legal entity. A
natural person can be a party. Certain organizations, such as corporations,
trusts and governments may also be recognized as a legal person and therefore
can be a party. Each party will be identified by name in relevant documents and
agreements. Actions of an automated program, including an electronic
agent, are deemed to be the actions of a party that used the program for that
purpose, under these Operating Rules.
Functions: The particular duties and obligations entered
into within a business and technical system. A Party will perform several
functions. These sets of functions are put together based on technical, legal
and business needs of the enterprise.
Role: Each role is named according to the nature
of the functions in each set. By naming roles, and associating functions with
roles, it is not suggested that in every business model sets of functions will
be divided in the same manner as here. Further, it is not suggested that there
will be one-to-one correlation between roles and parties. Indeed, it is
envisioned that a party may perform one or more roles. The purpose for
naming roles in this document is primarily to provide a vocabulary for creating
modular parts that can be perform by a given party entering the EMall system and
to organize the obligations and related documents associated with a given
party.
For example, rather than call the administration role by the
name Commonwealth of Massachusetts, it is convenient to name it based on the
relevant suite of functions so that any party could perform the role more easily
within the system of documents and business arrangements herein. Similarly,
while particular parties perform the role of service providers, there may be
additional and/or different parties playing those roles in the future, hence we
use terms like "solution provider" and "Certificate Manufacturer." The usage of
roles under these Operating Rules is intended to reflect and support the
potential evolution of this project from a relatively closed and small pilot to
a scalable production system in which many more parties may perform the roles
noted herein.
Documents and Agreements: In many cases, a party will
have to sign a document or submit a particular form as part of the functions
associated with a given role. These documents might be contracts, memoranda of
understanding, applications, reports and so on. These documents hold a
particular legal importance as the glue that hold together parties, roles and
functions in a predictable and enforceable system.
Pilot Participants: Every party that agrees to be bound
by the Operating Rules is considered to be a "Pilot Participant." This
general designation defines the closed community of people who are part of the
EMall pilot. All of the parties whose roles are described below (not
limited to Users alone) are also considered Pilot Participants because they all
agree to be bound by these Operating Rules and to operate within the pilot in
some authorized manner.
D.2. Role: Policy Authority (EMall
Team/Principal)Functions
* Sponsor of the Multi-State
EMall pilot;
* Makes all
policy decisions related to the Multi-State EMall pilot;
* Designates, and delegates appropriate
authority to EMall Administrators;
* Agrees to accept the MOU of State Partners; and
* Selects and arranges for
technology products and services necessary for hosting the EMall OBI-Compliant
server on behalf of State Partners as buying organizations.Relevant Documents and Agreements
* Promulgates, or delegates
authority to promulgate, these Operating Rules and all other official
agreements or documents related to the Multi-State EMall.
D.3. Role: Business Administrator (EMall
Team/Admin.)Functions
* Receives names/contact data
of each State Coordinator from each designated Partner State (from person(s) who
signed the MOU);
* Gives
the State Coordinator contact information to the Operations
Administrator;
* Reviews
and submits for processing all security related applications and forms,
including those related to Public Key Certificates, which are forwarded by the
State Coordinator; and
*
Securely maintains all applications and forms for related Public Key
Certificate requests before and after processing by the EMall Operations
Administrator.Relevant Documents and
Agreements
* Agrees to abide by these
Operating Rules.
*
Must sign Business Administrator Agreement.
D.4. Role: Operations Administrator (EMall
Team/Admin.)
Functions
* Responsible for
administering the EMall servers, including the IEC Server and the Database
Server;
* Responsible
for creating and/or amending and/or terminating User accounts and related User
authorizations on EMall system in accordance with instructions from EMall
Business Administrator; and
* Responsible for
accurately ascertaining the identity of an authorized User prior to performing a
password reset. Calling the purported User back at the pre-authorized
telephone number designated by that User's State Coordinator is a reasonable
basis for confirming the identity of an EMall User.
* Responsible for requesting Certificate Manufacturer to create
and deliver a Public Key Certificate to each authorized User.Relevant Documents and Agreements
* Agrees to abide by these
Operating Rules.
*
Must sign Operations Administrator Agreement governing
authorization rights and responsibilities to the EMall Server and related
matters.
D.5. Role: State Partner MOU Signatory (State
Partner/Principal)Functions
* Agrees to be an EMall Pilot
Participant by signing the State MOU;
* Designates the authorized Coordinator for the participating
State Partner; and
*
Sponsors a Supplier for participation in the EMall with a valid, current
contract with that state.Relevant Documents and
Agreements
* Signs the State MOU
that includes reference to agreement with policy materials (herein known as
these Operating Rules).
D.6. Role: State Coordinator (State
Partner/Contact)Functions
* Primary Operations and
Business point of contact for communications with EMall Administrators;
* Designates state Users and their respective
authorization rights, including designation as a Shopper, Approver, or
Receiver;
* Assists User
in application process and with use of the EMall system;
* Designates authorized Supplier
Partner(s); and
*
Immediately notifies the EMall Operations Administrator of changes in
authority (including termination) for any User or Supplier.Relevant Documents and Agreements
* Agrees to abide by these
Operating Rules. Signs State Coordinator Agreement and User
Designation and Authorization forms for each authorized User.
D.7. Role: Shopper (State Partner/User)NOTE: The role of Shopper is also known as "Requisitioner" for certain
technical purposes within the I.E.C. application and the EMall system.
Functions
* May shop on and through the
EMall system;
* May act, with the prior
permission of the EMall Operations Administrator, as a User of the EMall system
through the use of an Electronic Agent, as defined under the most current draft
or applicable enacted Uniform State Law, including Article 2 of the Uniform
Commercial Code, draft proposed Article 2B and the draft proposed Uniform
Electronic Transactions Act [links to official current drafts and related
information is available at: http://www.state.ma.us/itd/legal/agents);
* Must use system only for
authorized purposes and not use Public Key Certificate for any non-EMall pilot
purpose;
* For purposes
of this pilot, using an approved Internet Browser, as defined in the Technical
Requirements Section below, the Shopper will:
* shop available EMall
catalogs on the Web to determine best value;
* select a participating Supplier;
* access the Supplier's
storefront (electronic catalog) with contracted pricing in the EMall;
* select items to be
purchased;
* create an
OBI Order Request with the Supplier;
* verify in-house inventory availability as
appropriate;
* adjust
the OBI order request as necessary; and
* complete the OBI Order, flagging the OBI Order for
operational approval.Relevant Documents and
Agreements
* Agrees to abide by these
Operating Rules.
* Signs User
Agreement.
D.8. Role: Operational Approver (State
Partner/User)Functions
* May shop and must process
approved OBI Orders created by other Shoppers;
*
May act, with the prior permission of the EMall Operations Administrator, as a
User of the EMall system through the use of an Electronic Agent, as defined
under the most current draft or applicable enacted Uniform State Law, including
Article 2 of the Uniform Commercial Code, draft proposed Article 2B and the
draft proposed Uniform Electronic Transactions Act [links to official current
drafts and related information is available at: http://www.state.ma.us/itd/legal/agents);
* No Approver may approve an
OBI Order that they placed themselves unless they have been specifically
authorized by the appropriate personnel at their state and that authorization
has been successfully communicated to the EMall Administrator by the Approver's
Sate Coordinator (note: this exception will be approved in appropriate
circumstances, such as when a User works in a one person departments);
* For purposes of this pilot,
using an approved Internet Browser, as defined in the Technical Requirements
Section below, the Operational Approver will:
* review the OBI Order
Request;
* adjust the
OBI Order Request as necessary; and
* approve or deny the OBI Order Request on-line, flagging the
OBI Order for Financial Approval.Relevant
Documents and Agreements
* Agrees to abide by these
Operating Rules.
* Signs User
Agreement.
D.9. Role: Financial Approver (State
Partner/User)Functions
* May shop and must verify
that the appropriate "encumbrance" and payment related financial controls for
their state have been satisfied and documented;
*
May act, with the prior permission of the EMall Operations Administrator, as a
User of the EMall system through the use of an Electronic Agent, as defined
under the most current draft or applicable enacted Uniform State Law, including
Article 2 of the Uniform Commercial Code, draft proposed Article 2B and the
draft proposed Uniform Electronic Transactions Act [links to official current
drafts and related information is available at: http://www.state.ma.us/itd/legal/agents
* This role may be combined
with the Operational Approver;
* Must enter relevant "legacy system" encumbrance and payment
related numbers into the EMall system;
* For purposes of this pilot, using an approved Internet
Browser, as defined in the Technical Requirements Section below, and /or the
legacy accounting system as appropriate, the Financial Approver will:
* verify funds
availability;
* process
an encumbrance in the legacy accounting system known as: legacy system;
* cross-reference the legacy
system encumbrance and OBI Order Request for audit purposes and release the
detailed OBI Order for EDI 850 Transmission;
* review and adjust invoices submitted
for payment electronically in the EDI 810 format through the EMall;
* process payment in the legacy
accounting system known as: legacy system;
* update payment information on the OBI Order;
* financial approval must
ensure that an appropriate legacy system entry has been made before an OBI Order
is sent to the Supplier.Relevant Documents and
Agreements
* Agrees to abide by these
Operating Rules.
*
Signs User Agreement.
D.10. Role: Receiver (State
Partner/User)Functions
* Must indicate in the system
when commodities shipped as a result of an EMall OBI Order have been received in
full and/or part, making notations as appropriate concerning the exceptions
noted at the time of delivery;
* Must document
exceptions within the EMall system and any necessary legacy system;
* May act, with the prior permission of the EMall
Operations Administrator, as a User of the EMall system through the use of an
Electronic Agent, as defined under the most current draft or applicable enacted
Uniform State Law, including Article 2 of the Uniform Commercial Code, draft
proposed Article 2B and the draft proposed Uniform Electronic Transactions Act
[links to official current drafts is available at: http://civics.com/old-site/emall/www.law.upenn.edu/library/ulc/ulc.htm)
and additional non-binding, but helpful information can be found at: http://civics.com/old-site/emall/www.tiac.net/biz/danielg/agents/);
* For purposes of this pilot,
using an approved Internet Browser, as defined in the Technical Requirements
Section below, the Receiver will:
* accept and verify
commodities received;
*
record receipt of commodities in the EMall.Relevant Documents and Agreements
* Agrees to abide by these
Operating Rules.
*
Signs User Agreement.
D.11. Role: Supplier Partner MOU Signatory (Supplier
Partner/Principal)Functions
* Makes catalogs available
according to the OBI specification as implemented for EMall through the EMall
Operating Rules;
* Is an
authorized Supplier for purposes of doing business with the EMall Partner state
that sponsored that Supplier and with such other participating EMall Partner
States as agreed by the parties;
* Accepts the EMall transactional system (including the
various usages of authorized Public Key Certificates) and their own authorized
transaction server as a valid and binding method of transmitting quotes and
receiving orders (also known as OBI Order Requests and OBI Orders,
respectively), as specified under these Operating Rules;
* Designates Supplier
Coordinator.Relevant Documents and Agreements
* Agrees to abide by these
Operating Rules.
*
Signs Supplier MOU and the Electronic Commerce Supplier Partner
Agreement.
* Signed
respective contracts with the sponsoring state pursuant to applicable
procurements laws for purposes of doing business with that state.
D.12. Role: Supplier Coordinator (Supplier
Partner/Contact)Functions
* Primary Operations and
Business point of contact for EMall communications with the Supplier
Partner;
* Responsible for responding to delivery
or payment inquiries and disputes, including by use of the query function, as
available, within the EMall system.Relevant Documents
and Agreements
* Agrees to abide by these
Operating Rules.
D.13. Role: Certificate
ManufacturerFunctions
* Creates Public Key
Certificates as requested by EMall Operations Administrator;
* Creates said Certificates according to
the Certificate profile specified by EMall Policy Authority;
* Abides by the Certificate Policy
section of these Operating Rules.Relevant Documents
and Agreements
* Agrees to abide by these
Operating Rules, including Section C. Authentication Certificate
Policy (Certificate Policy), and warrants that any internal documented
practices, such as a Certificate Practice Statement, are consistent with these
Operating Rules and the included Certificate Policy.
* Signs Certificate Manufacturer
Agreement.
D.14. Role: Solution ProvidersFunctions
* Provide products and
services necessary for State Partners to conduct OBI-Compliant transactions via
the EMall;
* Conduct
initial system set up and testing;
* Upon agreement and request, provide ongoing support to the
EMall Operations Administrator as contracted and/or on a time and materials
basis.Relevant Documents and Agreements
* Agrees to abide by the
Operating Rules.
*
Signs contract and agrees to Task Order with Policy Authority for
provision of services and related products.
E. Technical Requirements
For this pilot, the State User Department agrees to comply with
the technical standards which are detailed below:
E.1. User Personal
Computer:The minimum computer
requirements and configuration is detailed below:
E.1.1. Internet and World
Wide Web ConnectivityA computer
capable of accessing the World Wide Web (WWW), which implies connectivity to the
Internet using the TCP/IP protocol.
E.1.2. Hardware:· Pentium Processor
· 32MB memory
· 10 MB of available disk space on the hard drive
· 10/100 Ethernet network interface card
· A mouse
· Year 2000 compliant
- Monitor: 17 inch or greater SVGA monitor, with a minimum of
800X600 pixels of resolution
· ADA compliant
E.1.3.
Software:· Windows 95 or Windows
NT 4.0 Workstation
· A 4.0 or higher version of the
Netscape Navigator or Internet Explorer browser to allow the use of Secure
Sockets Layer (SSL) 3.0
· A Public Key Certificate to
be installed within the User's browser and used to authenticate the identity of
a User will be issued by the Certificate Manufacturer contracted to provide
services to the EMall
· Year 2000 compliant.
· ADA compliant
Comparable hardware and software is acceptable but resolution
of problems arising from their use is the sole responsibility of the User's
department.
E.2. Supplier
PartnerEvery party that agrees to
perform the role of a Supplier Partner must, at a minimum, provide a web-based
catalog that is compliant with the OBI 1.1 specification, as referenced under
these Operating Rules.
E.3. Physical Security
of Computing and Network ResourcesThe EMall Web Server must be kept in a physically secure location such
that unauthorized persons can not gain physical access to the server without
breaking and entering. There are no physical security requirements for Users
during the course of the pilot, however, no User may permit an unauthorized
person to gain access to a computer that is currently accessing a restricted
area of the EMall server (that is, once a User logs onto the system with a user
name, password and Public Key Certificate, that User should not leave their
computer accessible to any other person until logging off the EMall server).
There are no physical security requirements for Suppliers during the course of
the pilot. The Certificate Manufacturer must assure that no unauthorized
personnel may gain physical access to the private key for the root Certificate
for this pilot or may otherwise become capable of manufacturing unauthorized
Public Key Certificates.
F. Duties and
Obligations of the Parties
F.1. Creation of Legally Binding
PurchasesA valid OBI Order must be
generated as the result of the authorized approval process specified in Section
D of these Operating Rules. Every valid and enforceable sale of
goods through the EMall pilot resulting from an OBI Order shall be subject
primarily to the underlying contracts between the relevant Supplier and State
User and also shall be subject to these Operating Rules and related agreements
as well as the terms and conditions within the OBI Order itself. In order
to be merged into the final terms of a purchase, any provisions inserted into an
OBI Order Request must conform to the OBI Specification as implemented within
the EMall pilot. The terms OBI Order Request and OBI Order
are to be construed in accordance with the OBI 1.1 specification, as referenced
in these Operating Rules. For purposes of this section, the term EMall
Server shall mean the web server hosted on behalf of the State Partners for
the purpose of conducting OBI-compliant transactions and shall include the EMall
Transaction Server referenced in Section C of these Operating Rules. For
purposes of this section, the term Supplier Server shall mean the web
server of a Supplier Partner for the purpose of conducting OBI-compliant
transactions, including the Supplier Transaction Server referenced in Section C.
of these Operating Rules.
F.1.1. OBI Order RequestAn
OBI Order Request shall constitute a contractual offer by the Supplier Partner
to sell the specified commodities at the specified price and other included
terms once it has been successfully posted by the Shopper's web browser to the
EMall Server at the agreed upon post-back URL.
F.1.2. OBI
OrderAn OBI Order shall constitute
a contractual acceptance by the transacting State Partner once it has been
successfully posted by the EMall Server to the Supplier Server at the agreed
upon post-back URL.
F.2. NoticeEvery
party that has been authorized as a participant after having signed and
delivered a participation agreement for the EMall pilot is entitled to notice of
any proposed amendment to these Operating Rules at least 14 calendar days prior
to said amendments taking effect, unless otherwise agreed by all the parties. In
the case of a State Partner, the person(s) who sign the State MOU and each
authorized State Coordinator are entitled to receive notice and may be requested
or required to pass along such notice to each subordinate User within their
state if appropriate. Notice may be communicated via e-mail, fax or other
reasonable means, however, unless notice is delivered via U.S. Postal Mail, the
Policy Authority must confirm that each party so entitled has in fact received
notice. An e-mailed reply confirming receipt by a party to the Policy
Authority is a valid means to confirm delivery of notice to that party.
F.3. Participation
AgreementsAs noted under these
Operating Rules, a party that performs an authorized role within the EMall must
sign an agreement, known generally as a Participation Agreement. A key function
of each Participation Agreement is to signify the assent of each party to abide
by these Operating Rules. Parties who will assume a role within the EMall pilot
may retrieve a current version of their respective agreements in PDF form from
the official EMall web site. These agreements must be completed, signed, and
returned to the EMall Business Administrator in order for any person to become
an authorized EMall Pilot Participant.
F.4. ConfidentialityUnless otherwise specified in these Operating Rules and related
agreements and to the extent permitted under applicable law, all personally
identifiable information related to the EMall pilot, including User information,
usage statistics related to an individual User, the names of administrators, any
telephone, address or other individually identifiable data should be considered
confidential and should not be disclosed to any person outside of the EMall
pilot. Similarly, no Pilot Participant should make any public statements
including press releases, information available on a web site and slide
presentation related to the EMall pilot or about any other person or
organization's participation in the EMall pilot, unless that statement has
first:
* appeared on the official
EMall web site, or
*
appeared in the public press, or
* been authorized by an EMall Administrator, or
* is a matter of public record under applicable
law
F.5. Intellectual
PropertyThese Operating Rules are
subject to Copyright by the Commonwealth of Massachusetts in its capacity as
sponsor of the Multi-State EMall. All rights reserved. Permission to reproduce
this document is hereby granted provided that the following limitations on this
right are observed: (1) all copies must clearly indicate that this work is
published by and attributed to the Commonwealth of Massachusetts in its capacity
as Policy Authority for and sponsor of the Multi-State EMall; and (2) all copies
must include this notice of copyright.
"Multi-State EMall" is a trademark of the Commonwealth of
Massachusetts.
F.6.
Alternative Dispute Resolution
Disputes
between a State User and a Supplier regarding the purchase of goods, including
pricing, quality or service guarantees and remedies, shall be governed according
to the terms and conditions contained within the underlying contract for the
purchase of goods as between those parties. Disputes arising out of or
related to the application of these Operating Rules and related Participation
Agreements shall be resolved in accordance with the provisions of these
Operating Rules and related agreements, and by agreement between the parties,
where possible, through direct negotiation or, if appropriate, through voluntary
mediation by a mutually agreed upon Mediator.
Depending upon the nature and gravity of a given dispute, as
well as the geographic distance of the parties, use of Online Alternative
Dispute services may be appropriate. Such services include the Virtual
Magistrate program (
http://vmag.vcilp.org/) and, generally, the services referred to in the
Massachusetts Information Technology Division's background paper on Online ADR
(
http://www.state.ma.us/itd/legal/adr.htm). Use of Online
Alternative Resolution services is explicitly permitted under these Operating
Rules, if otherwise agreed upon by all the parties. In the event that
parties are unable to reach agreement directly or through the use of mediation
or other voluntary methods of Alternative Dispute Resolution, then, to the
extent permitted by law and relevant regulation, all such disputes shall be
subject to binding arbitration by a a mutually agreed upon arbitrator of the
American Arbitration Association. The costs of any form of Alternative
Dispute Resolution shall be paid equally by the disputants or as otherwise
agreed by the parties.
Disputes
between a State User and a Supplier regarding the purchase of goods, including
pricing, quality or service guarantees and remedies, shall be governed according
to the law of jurisdiction so noted in the underlying contract for the purchase
of goods between those parties, or, if no such jurisdiction is so noted, then it
shall be deemed to be the laws of the state of the User. Disputes arising
out of or related to the application of these Operating Rules and related
Participation Agreements shall be governed according to the law of the
Commonwealth of Massachusetts.


- Elasticsearch
- Logstash
- Kibana
Analyze, Search,
Visualize
your data!

As your data set grows larger, your analytics will slow up, resulting in sluggish insights.
- How can you maintain valuable business insights?
- Use ELK !
- Centralize your logs
- Parse and gather only the fields you need
- Visualize your logs and identify the information quickly
- Logstash : Processes incoming logs
- Elasticsearch : Stores all of the logs
- Kibana : Web interface for searching and visualizing logs
Logstash
- Centralize data processing of all types
- Normalize varying schema and formats
- Quickly extend to custom log formats
- Easily add plugins for custom data sources
Elasticsearch
- Distributed, scalable, and highly available
- Real-time search and analytics capabilities
- Sophisticated RESTful API
Kibana
- Flexible analytics and visualization platform
- Real-time summary and charting of streaming data
- Intuitive interface for a variety of users
- Instant sharing and embedding of dashboards
Docker ELK
- You can use my stack on Docker, all you need is just to set up your Logstash configurations !
- Docker ELK repository
- Follow the tutorial (in French)
- Enjoy !
With my Docker ELK, locally...
...or with a more advanced solution
...in your new projects to format your logs correctly.
...set up this solution while you build your app.
- A small tip I can give you is to add an ID in your app which, for example, helps you follow a request through different services.
- In Kibana, you'll be able to see all the logs related to that request


---
layout: default
title: Wikia Style Guide
---
Style guide
Front-end framework made easy.
This is Wikia's first draft of a style guide and represents a work-in-progress, with the goal of changing in smaller increments over time, as styles are tested with real world use cases.
The document is primarily aimed at international designers and developers at this time in order to drive greater consistency across design and front-end development, but it is available to anyone interested.
The style guide will be evolved in the context of larger projects, in order to test use cases in a live environment with the broader Wikia community.
Known upcoming projects include:


{% extends 'base.html' %} {% load staticfiles %} {% block navpadding %}{% endblock %} {% block content %} Contact Us We want to hear what you think We hope you're enjoying MyGeneRank, and if you are we'd love to hear from you. If you're having any issues, we want to hear that too. You can get in contact with us on Twitter, or email our support team. Twitter<EMAIL_ADDRESS>{% endblock %}
We want to hear what you think
We hope you're enjoying MyGeneRank, and if you are we'd love to hear from you. If you're having any issues, we want to hear that too.
You can get in contact with us on Twitter, or email our support team.


Graph will start animating when music is loaded
For more information on how this is done look at
this article.
.


The Digital India programme is centred on three key vision areas:
Digital Infrastructure as a Core Utility to Every Citizen
Availability of high speed internet as a core utility for delivery of services to citizens.
Cradle to grave digital identity that is unique, lifelong, online and authenticable to every
citizen.
Mobile phone & bank account enabling citizen participation in digital & financial space.
Easy access to a Common Service Centre.
Shareable private space on a public cloud.
Safe and secure cyber-space.
Governance & Services on Demand
Seamlessly integrated services across departments or jurisdictions.
Availability of services in real time from online & mobile platforms.
All citizen entitlements to be portable and available on the cloud.
Digitally transformed services for improving ease of doing business.
Making financial transactions electronic & cashless.
Leveraging Geospatial Information Systems (GIS) for decision support systems & development.
Digital Empowerment of Citizens
Universal digital literacy.
Universally accessible digital resources.
Availability of digital resources / services in Indian languages.
Collaborative digital platforms for participative governance.
Citizens not required to physically submit Govt. documents / certificates.
Approach and Methodology for Digital India Programme are:
Ministries / Departments / States would fully leverage the Common and Support ICT Infrastructure
established by GoI. DeitY would also evolve/ lay down standards and policy guidelines, provide
technical and handholding support, undertake capacity building and R&D etc.
The existing/ ongoing e-governance initiatives would be suitably revamped to align them with the
principles of Digital India. Scope enhancement, Process Reengineering, use of integrated &
interoperable systems and deployment of emerging technologies like cloud & mobile would be
undertaken to enhance the delivery of Government services to citizens.
States would be given flexibility to identify for inclusion additional state-specific projects,
which are relevant for their socio-economic needs.
e-Governance would be promoted through a centralised initiative to the extent necessary, to ensure
citizen-centric service orientation, interoperability of various e-Governance applications and
optimal utilisation of ICT infrastructure/ resources, while adopting a decentralised implementation
model.
Successes would be identified and their replication promoted proactively with the required
productisation and customisation wherever needed.
Public Private Partnerships would be preferred wherever feasible to implement e-governance projects
with adequate management and strategic control.
Adoption of Unique ID would be promoted to facilitate identification, authentication and delivery of
benefits.
Restructuring of NIC would be undertaken to strengthen the IT support to all government departments
at the Centre and the State levels.
The positions of Chief Information Officers (CIO) would be created in at least 10 key Ministries so
that various e-governance projects could be designed, developed and implemented faster. CIO
positions will be at Additional Secretary/Joint Secretary level with over-riding powers on IT in the
respective Ministry.


Integrate fax capabilities into your own applications. The Fax API uses TLS 1.2 encryption for fax transmissions, and AES 256-bit encryption for fax storage and is 100% HIPAA Compliant out of the box!
 If you have any ideas for other articles or questions email us here.
These are environments where you can rapidly prototype your code for integration. Postman is a great tool for testing and outputting production ready code and Swaggerhub allows you to “Try Out” the call and test a process.
Transform your business processes while dramatically improving productivity by adding the ability to fax from within
your mission-critical software applications. The WestFax Fax API can be
used to integrate WestFax’s Robust Fax Service with many different applications. No more trips to the fax machine or
wondering if a fax went through and must be re-sent.
Detailed setup documentation and our guarantee for technical support ensures your IT team can have applications “fax
capable” in just a few hours. Integrate the fax functionality any way you want: from an application’s File menu, as
a button, or even through a web page.
Use it to send outbound faxes wherever you might be whether on the road or in the office. Because its designed for
enterprise-level applications, The WestFax Fax API offers unlimited
scalability. Plus, with the industry-leading resources of WestFax, Inc. behind it, you can be assured your faxes
always go through safely and securely.
If you’re a developer we’d love to hear about your project needs! Every project is unique, so give us a call or
complete our Developer Registration form to communicate
directly with our technical team.
WestFax offers a fully HIPAA-PCI Certified fax API with an easy to use Restful interface. We go beyond HIPAA requirements to provide an industry-leading secure fax solution. SSL/PKI encryption of faxes on server and the only PCI-DSS Certified faxing service. Transmit medical information more efficiently via fax without compromising security.
Fax from any development environment. Our fax solution easily integrates with the leading EMRs, EHRs, and Clinical Management platforms. From XML, JSON and/or SOAP message encoding to Java, C# and PHP. Our flexible and consistent API interface makes your fax project a reality.
Our geographically diverse network provides 99.9% up-time. Our network architecture has the capacity and speed to scale with your business and will deliver the first dialing attempt within 60 seconds. The WestFax topology aware intelligent network provides the highest successful delivery rate.
By Developers. Our off-the-shelf PHP and .NET SDKs and code samples greatly simplify the development and implementation effort required to get you up and running with API faxing. Our technical team will assist you in the application process making recommendations of best practices tailored to your needs.


Use the layout
directive on a container element to specify the layout direction for
its children: horizontally in a row (layout="row"
) or vertically in a column
(layout="column"
). Note that row
is the default layout direction if you
specify the layout
directive without a value.
For the demo below, as you shrink your browser window width notice the flow
direction changes to column
for mobile devices (xs
).
And as you expand it will reset to row
for gt-sm
view sizes.
[flex-order="-1"]
[flex-order="1"]
[flex-order-gt-md="3"]
[flex-order="2"]
[flex-order="3"]
[flex-order-gt-md="1"]


You may import unmodified PDFs from Paizo only. For personal use only.
This will create actors/scenes/journal entries in this world. Importing supported flip mats/interactive maps (+) will update maps for all matching scenes in the world.
Fall of Plaguestone
The Slithering
Troubles in Otari
Menace Under Otari
+Little Trouble..
Sundered Waves
Dinner at Lionlodge
Age of Ashes
1 2 3 4 5 6Extinction Curse
1 2 3 4 5 6Agents of Edgewatch
1+ 2+ 3+ 4+ 5+ 6+Abomination Vaults
1+ 2+ 3+Pathfinder Society Season 1
Pathfinder Society Season 2
Bounties
Super Patrons: Roy, gfactor, Avery Prometheus Rosen, and Conor McCormick


“Let the Baby Die” Signs Aimed at Child Fighting Rare Birth Disorders
Family shocked at vile messages calling for son’s death
An Ohio family says they are shocked after signs appeared demanding they “let the baby die,” instead of fundraising for their young son afflicted with multiple rare birth disorders.
Father KC Ahlers says the vile messages were erected in response to signs he had posted around a local mall explaining his child’s situation and requesting assistance from the Toledo community.
“Stop asking for money.  It’s called Darwinism. Happy Holidays,” the signs read.
“It shocked me. I mean it really shocked me that somebody would have that kind of cruelty,” Ahlers told local media. “I came out. I saw it. Immediately took the one down. There were other ones that were up, but somebody, some other good Samaritans kicked them down.”
Ahlers says his son RJ has two birth disorders, one relating to a chromosome abnormality, and another which affects his brain.
The boy also has a hole in his heart, which does not allow most babies to live past the age of two.
“We want to raise our son to not reciprocate hatred,” Ahlers said. “We want to battle hatred with love. So, we obviously know somebody that did this is disturbed and we hope they get help. But, we’re going to keep taking your signs down as we see them because this town doesn’t need hatred. This town needs love.”
A fundraiser for baby RJ can be found here.
Larry Nichols joins The Alex Jones Show to break down the corrupt establishment’s intentions to crush the will of the people.
The Black Friday sales have arrived early! Get up to 70% off our hottest products as well as free-shipping and double Patriot Points while the sale lasts!


Generates two kinds of uniform test datasets.
Parameters
Name Type Description UI Control pattern int The pattern of the output field Toggle Width int The Width of the output field Slider Height int The height of the output field Slider Num_frames int The number of frames in the output field Slider
Output Ports
Name Type Description out Mesh+Data Uniform field of test data
GenerateTestData can generate two kinds of uniform fields. The Field is constructed by a number of frames that have their size defined by the Width and Height parameters. The pattern parameter decides the types of output field. If pattern is 0, the frames in the ouput field are assigned a uniform value. The value of each frame is increased progressively from the bottom frame to the top frame. If pattern is 1, each frame has linear increasing node data values from one side to the other side,
Note: The data type of the output field is integer.
Pattern
Pattern has two possible values 0 or 1. Value 0 generates progressively increasing uniform field from bottom to top. Value 1 generates progressively increasing node data in each frame.
Width
The width of output field and also the width of each frame.
Height
The height of output field and also the height of each frame.
Num_frames
The number of frames in the output field
out
The output field contains uniform mesh data and progressively increasing node data.
The User Macro GenerateTestData makes use of the Functional Macro GenerateTestDataFunc and the UI Macro GenerateTestDataUI.
An example application GenerateTestDataEg is provided, which demonstrates the structure of test data field using both orthoslice and isosurface.
xp_comm_proj/gentest/gtstmods.v contains the V definitions of the GenerateTestDataParams parameter block and the Generate_Test_Data module.
xp_comm_proj/gentest/gtstmacs.v contains the V definitions of the GenerateTestDataFunc Functional Macro, the GenerateTestDataUI User Interface Macro, and the GenerateTestData User Macro.
xp_comm_proj/gentest/gtstapps.v contains the V definition of the example application GenerateTestDataEg.
Dave Goughnour Advanced Visual Systems, Inc.
MA YingLiang Manchester Visualization Centre


--- layout: post title: 'Review: The Ascent of Money: A Financial History of the World' date: 2012-06-20 22:47:06.000000000 -05:00 type: post parent_id: '0' published: true password: '' status: publish categories: [] tags: [] meta: _wpas_done_twitter: '1' author: login: dreamessenceonthemove email<EMAIL_ADDRESS>display_name: darribas first_name: Daniel last_name: Arribas-Bel permalink: "/2012/06/20/review-the-ascent-of-money-a-financial-history-of-the-world/" ---
The Ascent of Money: A Financial History of the World by Niall Ferguson
My rating: 3 of 5 stars
The book is an overview of the history of finance and banking, from its rudimentary origins in Mesopotamia and Europe to the current financial engineering from Wall St. I think it stands as a very accessible entry gate to this particular world ("Planet Finance" as he calls it) and does a good job at presenting the topic in both an attractive and easy to understand for a non-familiarized audience.
On the minus side, I would highlight the fact that the author is clearly biased and very partial in several passages of the book. His conservative views, "understanding" of the right-wing rich world and uneasiness with more liberal characters such as P. Krugman or G. Soros make the more left-wing reader feel like he is only being shown one part of the story. In effect, there are very few instances where the author alludes to the social consecuences of some of the financial decisions made by the brilliant and successful people he presents and seems to adore. The good news is that it is so obvious when he is being partial that it makes it easier to catch and allows to better cast a shadow of doubt and criticism, something absent in the manuscript.
All in all, I think it is a book that does a decent job at educating a broad audicence and that, although (or rather because) it takes a long-term perspective, today more than ever is a recommened read.


Place: City Hall of Fortaleza
Occupation: Information Systems Programmer
Period: Oct/2017 current
Place: Vice Governorship of the State of Ceara
Occupation: Programmer
Period: Jun/2017 until Sep/2017
Place: City Hall of Fortaleza (Temporary Server)
Occupation: Information Systems Programmer
Period: Jul/2015 until May/2017
Place: Group of Computer Networks, Software Engineering and Systems GREat - UFC
Occupation: Junior Systems Analyst
Period: Jan/2013 until Jul/2015
Place: 3E Engineering and Energy Efficiency
Occupation: Web Programmer
Period: Feb/2012 until Oct/2012
Place: HDMais Development Sites
Occupation: Programmer
Period: Jan/2010 until Oct/2010
Place: CG Management Consulting
Occupation: Web Programmer
Period: Feb/2009 until Aug/2009
Place: GNial Sistemas
Occupation: Junior Programmer
Period: 2 months
Place: Pipa Digital
Occupation: Junior Programmer
Period: 4 months
Place: XACT Tecnologia
Occupation: Internship as Programmer
Period: 1 mês
Place: PC4
Occupation: Internship as Programmer / Programmer
Period: 7 months
Place: Adventist College of Fortaleza
Occupation: Computer Support
Period: 2 months
Place: Walter Marinho (Marglass)
Occupation: Administrative Assistant
Period: Jan/2006 until May/2007
Place: Moinho Santa Lúcia (Predilleto)
Occupation: Administrative Assistant
Period: Jul/2005 until Apr/2006
Place: Fortaleza's Finance Department
Course: GGIS with Spatial Data
Workload: 20h / class
Place: Data Science Academy
Course: Python Fundamentals for Data Analysis
Workload: 42h / class
Place: edX
Course: Introduction to Python for Data Science
Workload: 24h / class
Place: Oncase Intelligence Consulting
Course: Pentaho Data Integration
Workload: 72h / class
Place: Milfont Consulting
Course: Ruby on Rails
Workload: 40h / class
Place: University of Fortaleza
Course: Java Programming Language
Workload: 40h / class
Place: AlgaWorks
Course: JPA and Hibernate beyond basics
Workload: 60h / class
Place: CLEC
Course: English (incomplete third semester)
Place: Others
English: Read, Listen and Write (Intermediate); Speak (Basics);
Postuguese Brazil: Fluent;


Semester: VI
Introduction and Line Generation: Types of computer graphics, Graphic DisplaysRandom scan displays, Raster scan displays, Frame buffer and video controller, Points and lines, Line drawing algorithms, Circle generating algorithms, Mid-point circle generating algorithm, and parallel version of these algorithms.
Transformations: Basic transformation, Matrix representations and homogenous coordinates, Composite transformations, Reflections and shearing. Windowing and Clipping: Viewing pipeline, Viewing transformations, 2-D Clipping algorithms- Line clipping algorithms such as Cohen Sutherland line clipping algorithm, Liang Barsky algorithm, Line clipping against non rectangular clip windows; Polygon clipping – Sutherland Hodgeman polygon clipping, Weiler and Atherton polygon clipping, Curve clipping, Text clipping
Three Dimensional: 3-D Geometric Primitives, 3-D Object representation, 3-D Transformation, 3-D viewing, projections, 3-D Clipping.
Curves and Surfaces: Quadric surfaces, Spheres, Ellipsoid, Blobby objects, Introductory concepts of Spline, Bspline and Bezier curves and surfaces.

Goals and Applications of Networks : , Network structure and architecture, The OSI reference model, services, Network Topology Design - Delay Analysis, Back Bone Design, Local Access Network Design, Physical Layer Transmission Media, Switching methods, ISDN, Terminal Handling
Medium Access sub layer : Medium Access sub layer - Channel Allocations, LAN protocols - ALOHA protocols - Overview of IEEE standards - FDDI. Data Link Layer - Elementary Data Link Protocols, Sliding Window protocols, Error Handling.
Network Layer : Network Layer - Point - to Pont Networks, routing, Congestion control Internetworking -TCP / IP, IP packet, IP address, IPv6.
Transport Layer : Transport Layer - Design issues, connection management, session Layer-Design issues, remote procedure call. Presentation Layer-Design issues, Data compression techniques, cryptography - TCP - Window Management.
Application Layer : File Transfer, Access and Management, Electronic mail, Virtual Terminals, Other application. Example Networks - Internet and Public Networks
Data Warehousing: Overview, Definition, Data Warehousing Components, Building a Data Warehouse, Warehouse Database, Mapping the Data Warehouse to a Multiprocessor Architecture, Difference between Database System and Data Warehouse, Multi Dimensional Data Model, Data Cubes, Stars, Snow Flakes, Fact Constellations, Concept.
Data Warehouse Process and Technology: Warehousing Strategy, Warehouse management and Support Processes, Warehouse Planning and Implementation, Hardware and Operating Systems for Data Warehousing, Client/Server Computing Model & Data Warehousing. Parallel Processors & Cluster Systems, Distributed DBMS implementations, Warehousing Software, Warehouse Schema Design
Classification : Data Generalization, Analytical Characterization, Analysis of attribute relevance, Mining Class comparisons, Statistical measures in large Databases, Statistical-Based Algorithms, Distance-Based Algorithms, Decision Tree-Based Algorithms. Clustering: Introduction, Similarity and Distance Measures, Hierarchical and Partitional Algorithms. Hierarchical Clustering-CURE and Chameleon. Density Based Methods-DBSCAN, OPTICS. Grid Based Methods-STING, CLIQUE. Model Based Method –Statistical Approach, Association rules: Introduction, Large Item sets, Basic Algorithms, Parallel and Distributed Algorithms, Neural Network approach.
Data Visualization and Overall Perspective : Aggregation, Historical information, Query Facility, OLAP function and Tools. OLAP Servers, ROLAP, MOLAP, HOLAP, Data Mining interface, Security, Backup and Recovery, Tuning Data Warehouse, Testing Data Warehouse. Warehousing applications and Recent Trends: Types of Warehousing Applications, Web Mining, Spatial Mining and Temporal Mining
Introduction to Compiler: Phases and passes, Bootstrapping, Finite state machines and regular expressions and their applications to lexical analysis, Optimization of DFA-Based Pattern Matchers implementation of lexical analyzers, lexical-analyzer generator, LEX compiler, Formal grammars and their application to syntax analysis, BNF notation, ambiguity, YACC. The syntactic specification of programming languages: Context free grammars, derivation and parse trees, capabilities of CFG.
Basic Parsing Techniques:Parsers, Shift reduce parsing, operator precedence parsing, top down parsing, predictive parsers Automatic Construction of efficient Parsers: LR parsers, the canonical Collection of LR(0) items, constructing SLR parsing tables, constructing Canonical LR parsing tables, Constructing LALR parsing tables, using ambiguous grammars, an automatic parser generator, implementation of LR parsing tables.
Syntax-directed Translation: Syntax-directed Translation schemes, Implementation of Syntax-directed Translators, Intermediate code, postfix notation, Parse trees & syntax trees, three address code, quadruple & triples, translation of assignment statements, Boolean expressions, statements that alter the flow of control, postfix translation, translation with a top down parser. More about translation: Array references in arithmetic expressions, procedures call, declarations and case statements
Symbol Tables: Data structure for symbols tables, representing scope information. RunTime Administration: Implementation of simple stack allocation scheme, storage allocation in block structured language. Error Detection & Recovery: Lexical Phase errors, syntactic phase errors semantic errors.
Code Generation:Design Issues, the Target Language. Addresses in the Target Code, Basic Blocks and Flow Graphs, Optimization of Basic Blocks, Code Generator. Code optimization: Machine-Independent Optimizations, Loop optimization, DAG representation of basic blocks, value numbers and algebraic laws, Global Data-Flow analysis.
Industrial Sociology: Nature and Scope of Industrial Sociology-Development of Industrial Sociology.
Rise and Development of Industry : Early Industrialism – Types of Productive Systems – The Manorial or Feudal system – The guild system – The domestic or putting-out system – and the factory system – Characteristics of the factory system – causes and Consequences of industrialization.
Industrialization in India : Industrial Poling Resolutions – 1956.
Contemporary Issues : Grievances and Grievance handling Procedure. Industrial Disputes : courses, strikes & lockouts, Industrial Relations Machinery Bi-partite & Tri-partite Agreement, Labour courts & Industrial Tribunals, Code of Discipline, Standing order.
Introduction : Concept, Development, application and scope of Industrial Management. Productivity : measurement, productivity index, types of production system, Industrial Ownership.
Management Function : Principle of Management – Time and motion study, work simplification – process charts and flow diagrams, Production Planning.
Inventory Control : Inventory, Cost, Deterministic Models, Introduction to supply chain management
Quality Control : Process control, SQC, Control charts, Single, Double and Sequential Sampling, Introduction to TQM.


$(if refresh-timeout) $(endif) $(if refresh-timeout) $(endif)
Your requested URL is this.
$(endif)$(if error)$(error)$(endif)
| This Session bytes up/down | $(bytes-in-nice) / $(bytes-out-nice) |
| This Session connected time | $(uptime) |
| Your Time left: | $(session-time-left) |
| Megabytes Remaining: | |
| status: |
advertisement required |
| status refresh: | $(refresh-timeout) |
| Logged in By: | $(login-by) |
| Mac Address : | $(mac) |
| Ip Address : | $(ip) |


Sarah DeBey
Home
About Me
Github
LinkedIn
-- Filter by Project Name --
My projects on Github
Code projects go here


| Top |
The GtkClipboard object represents a clipboard of data shared
between different processes or between different widgets in
the same process. Each clipboard is identified by a name encoded as a
GdkAtom. (Conversion to and from strings can be done with
gdk_atom_intern()
and gdk_atom_name()
.) The default clipboard
corresponds to the “CLIPBOARD” atom; another commonly used clipboard
is the “PRIMARY” clipboard, which, in X, traditionally contains
the currently selected text.
To support having a number of different formats on the clipboard
at the same time, the clipboard mechanism allows providing
callbacks instead of the actual data. When you set the contents
of the clipboard, you can either supply the data directly (via
functions like gtk_clipboard_set_text()
), or you can supply a
callback to be called at a later time when the data is needed (via
gtk_clipboard_set_with_data()
or gtk_clipboard_set_with_owner()
.)
Providing a callback also avoids having to make copies of the data
when it is not needed.
gtk_clipboard_set_with_data() and gtk_clipboard_set_with_owner()
are quite similar; the choice between the two depends mostly on
which is more convenient in a particular situation.
The former is most useful when you want to have a blob of data
with callbacks to convert it into the various data types that you
advertise. When the clear_func
you provided is called, you
simply free the data blob. The latter is more useful when the
contents of clipboard reflect the internal state of a GObject
(As an example, for the PRIMARY clipboard, when an entry widget
provides the clipboard’s contents the contents are simply the
text within the selected region.) If the contents change, the
entry widget can call gtk_clipboard_set_with_owner()
to update
the timestamp for clipboard ownership, without having to worry
about clear_func
being called.
Requesting the data from the clipboard is essentially
asynchronous. If the contents of the clipboard are provided within
the same process, then a direct function call will be made to
retrieve the data, but if they are provided by another process,
then the data needs to be retrieved from the other process, which
may take some time. To avoid blocking the user interface, the call
to request the selection, gtk_clipboard_request_contents()
takes a
callback that will be called when the contents are received (or
when the request fails.) If you don’t want to deal with providing
a separate callback, you can also use gtk_clipboard_wait_for_contents()
.
What this does is run the GLib main loop recursively waiting for
the contents. This can simplify the code flow, but you still have
to be aware that other callbacks in your program can be called
while this recursive mainloop is running.
Along with the functions to get the clipboard contents as an
arbitrary data chunk, there are also functions to retrieve
it as text, gtk_clipboard_request_text()
and
gtk_clipboard_wait_for_text()
. These functions take care of
determining which formats are advertised by the clipboard
provider, asking for the clipboard in the best available format
and converting the results into the UTF-8 encoding. (The standard
form for representing strings in GTK+.)
void (*GtkClipboardReceivedFunc) (GtkClipboard *clipboard
,GtkSelectionData *selection_data
,gpointer data
);
A function to be called when the results of gtk_clipboard_request_contents()
are received, or when the request fails.
clipboard |
the GtkClipboard |
|
selection_data |
a GtkSelectionData containing the data was received.
If retrieving the data failed, then then length field
of |
|
data |
the |
[closure] |
void (*GtkClipboardTextReceivedFunc) (GtkClipboard *clipboard
,const gchar *text
,gpointer data
);
A function to be called when the results of gtk_clipboard_request_text()
are received, or when the request fails.
clipboard |
the GtkClipboard |
|
text |
the text received, as a UTF-8 encoded string, or
|
[nullable] |
data |
the |
[closure] |
void (*GtkClipboardImageReceivedFunc) (GtkClipboard *clipboard
,GdkPixbuf *pixbuf
,gpointer data
);
A function to be called when the results of gtk_clipboard_request_image()
are received, or when the request fails.
clipboard |
the GtkClipboard |
|
pixbuf |
the received image |
|
data |
the |
[closure] |
Since: 2.6
void (*GtkClipboardTargetsReceivedFunc) (GtkClipboard *clipboard
,GdkAtom *atoms
,gint n_atoms
,gpointer data
);
A function to be called when the results of gtk_clipboard_request_targets()
are received, or when the request fails.
clipboard |
the GtkClipboard |
|
atoms |
the supported targets,
as array of GdkAtom, or |
[nullable][array length=n_atoms] |
n_atoms |
the length of the |
|
data |
the |
[closure] |
Since: 2.4
void (*GtkClipboardRichTextReceivedFunc) (GtkClipboard *clipboard
,GdkAtom format
,const guint8 *text
,gsize length
,gpointer data
);
A function to be called when the results of
gtk_clipboard_request_rich_text()
are received, or when the request
fails.
clipboard |
the GtkClipboard |
|
format |
The format of the rich text |
|
text |
the rich text received, as
a UTF-8 encoded string, or |
[nullable][type utf8] |
length |
Length of the text. |
|
data |
the |
[closure] |
Since: 2.10
void (*GtkClipboardURIReceivedFunc) (GtkClipboard *clipboard
,gchar **uris
,gpointer data
);
A function to be called when the results of
gtk_clipboard_request_uris()
are received, or when the request
fails.
clipboard |
the GtkClipboard |
|
uris |
the received URIs. |
[array zero-terminated=1] |
data |
the |
[closure] |
Since: 2.14
void (*GtkClipboardGetFunc) (GtkClipboard *clipboard
,GtkSelectionData *selection_data
,guint info
,gpointer user_data_or_owner
);
A function that will be called to provide the contents of the selection.
If multiple types of data were advertised, the requested type can
be determined from the info
parameter or by checking the target field
of selection_data
. If the data could successfully be converted into
then it should be stored into the selection_data
object by
calling gtk_selection_data_set()
(or related functions such
as gtk_selection_data_set_text()
). If no data is set, the requestor
will be informed that the attempt to get the data failed.
clipboard |
the GtkClipboard |
|
selection_data |
a GtkSelectionData argument in which the requested data should be stored. |
|
info |
the info field corresponding to the requested target from the
GtkTargetEntry array passed to |
|
user_data_or_owner |
the |
void (*GtkClipboardClearFunc) (GtkClipboard *clipboard
,gpointer user_data_or_owner
);
A function that will be called when the contents of the clipboard are changed
or cleared. Once this has called, the user_data_or_owner
argument
will not be used again.
clipboard |
the GtkClipboard |
|
user_data_or_owner |
the |
GtkClipboard * gtk_clipboard_get_for_display (GdkDisplay *display
,GdkAtom selection
);
Since: 2.2
GdkDisplay *
gtk_clipboard_get_display (GtkClipboard *clipboard
);
Since: 2.2
GtkClipboard *
gtk_clipboard_get_default (GdkDisplay *display
);
Returns the default clipboard object for use with cut/copy/paste menu items and keyboard shortcuts.
Since: 3.16
gboolean gtk_clipboard_set_with_data (GtkClipboard *clipboard
,const GtkTargetEntry *targets
,guint n_targets
,GtkClipboardGetFunc get_func
,GtkClipboardClearFunc clear_func
,gpointer user_data
);
[skip]
gboolean gtk_clipboard_set_with_owner (GtkClipboard *clipboard
,const GtkTargetEntry *targets
,guint n_targets
,GtkClipboardGetFunc get_func
,GtkClipboardClearFunc clear_func
,GObject *owner
);
[skip]
void
gtk_clipboard_clear (GtkClipboard *clipboard
);
Clears the contents of the clipboard. Generally this should only
be called between the time you call gtk_clipboard_set_with_owner()
or gtk_clipboard_set_with_data()
,
and when the clear_func
you supplied is called. Otherwise, the
clipboard may be owned by someone else.
void gtk_clipboard_set_text (GtkClipboard *clipboard
,const gchar *text
,gint len
);
Sets the contents of the clipboard to the given UTF-8 string. GTK+ will make a copy of the text and take responsibility for responding for requests for the text, and for converting the text into the requested format.
clipboard |
a GtkClipboard object |
|
text |
a UTF-8 string. |
|
len |
length of |
void gtk_clipboard_set_image (GtkClipboard *clipboard
,GdkPixbuf *pixbuf
);
Sets the contents of the clipboard to the given GdkPixbuf. GTK+ will take responsibility for responding for requests for the image, and for converting the image into the requested format.
Since: 2.6
void gtk_clipboard_request_contents (GtkClipboard *clipboard
,GdkAtom target
,GtkClipboardReceivedFunc callback
,gpointer user_data
);
void gtk_clipboard_request_text (GtkClipboard *clipboard
,GtkClipboardTextReceivedFunc callback
,gpointer user_data
);
void gtk_clipboard_request_image (GtkClipboard *clipboard
,GtkClipboardImageReceivedFunc callback
,gpointer user_data
);
Since: 2.6
void gtk_clipboard_request_targets (GtkClipboard *clipboard
,GtkClipboardTargetsReceivedFunc callback
,gpointer user_data
);
Since: 2.4
void gtk_clipboard_request_rich_text (GtkClipboard *clipboard
,GtkTextBuffer *buffer
,GtkClipboardRichTextReceivedFunc callback
,gpointer user_data
);
Since: 2.10
void gtk_clipboard_request_uris (GtkClipboard *clipboard
,GtkClipboardURIReceivedFunc callback
,gpointer user_data
);
Since: 2.14
GtkSelectionData * gtk_clipboard_wait_for_contents (GtkClipboard *clipboard
,GdkAtom target
);
GdkPixbuf *
gtk_clipboard_wait_for_image (GtkClipboard *clipboard
);
Since: 2.6
guint8 * gtk_clipboard_wait_for_rich_text (GtkClipboard *clipboard
,GtkTextBuffer *buffer
,GdkAtom *format
,gsize *length
);
Since: 2.10
gchar **
gtk_clipboard_wait_for_uris (GtkClipboard *clipboard
);
Since: 2.14
gboolean
gtk_clipboard_wait_is_text_available (GtkClipboard *clipboard
);
Test to see if there is text available to be pasted This is done by requesting the TARGETS atom and checking if it contains any of the supported text targets. This function waits for the data to be received using the main loop, so events, timeouts, etc, may be dispatched during the wait.
This function is a little faster than calling
gtk_clipboard_wait_for_text()
since it doesn’t need to retrieve
the actual text.
gboolean
gtk_clipboard_wait_is_image_available (GtkClipboard *clipboard
);
Test to see if there is an image available to be pasted This is done by requesting the TARGETS atom and checking if it contains any of the supported image targets. This function waits for the data to be received using the main loop, so events, timeouts, etc, may be dispatched during the wait.
This function is a little faster than calling
gtk_clipboard_wait_for_image()
since it doesn’t need to retrieve
the actual image data.
Since: 2.6
gboolean gtk_clipboard_wait_is_rich_text_available (GtkClipboard *clipboard
,GtkTextBuffer *buffer
);
Test to see if there is rich text available to be pasted This is done by requesting the TARGETS atom and checking if it contains any of the supported rich text targets. This function waits for the data to be received using the main loop, so events, timeouts, etc, may be dispatched during the wait.
This function is a little faster than calling
gtk_clipboard_wait_for_rich_text()
since it doesn’t need to retrieve
the actual text.
Since: 2.10
gboolean
gtk_clipboard_wait_is_uris_available (GtkClipboard *clipboard
);
Test to see if there is a list of URIs available to be pasted This is done by requesting the TARGETS atom and checking if it contains the URI targets. This function waits for the data to be received using the main loop, so events, timeouts, etc, may be dispatched during the wait.
This function is a little faster than calling
gtk_clipboard_wait_for_uris()
since it doesn’t need to retrieve
the actual URI data.
Since: 2.14
gboolean gtk_clipboard_wait_for_targets (GtkClipboard *clipboard
,GdkAtom **targets
,gint *n_targets
);
Since: 2.4
gboolean gtk_clipboard_wait_is_target_available (GtkClipboard *clipboard
,GdkAtom target
);
Checks if a clipboard supports pasting data of a given type. This function can be used to determine if a “Paste” menu item should be insensitive or not.
If you want to see if there’s text available on the clipboard, use
gtk_clipboard_wait_is_text_available()
instead.
Since: 2.6
void gtk_clipboard_set_can_store (GtkClipboard *clipboard
,const GtkTargetEntry *targets
,gint n_targets
);
Since: 2.6
void
gtk_clipboard_store (GtkClipboard *clipboard
);
Stores the current clipboard data somewhere so that it will stay around after the application has quit.
Since: 2.6
GdkAtom
gtk_clipboard_get_selection (GtkClipboard *clipboard
);
Since: 3.22
“owner-change”
signalvoid user_function (GtkClipboard *clipboard, GdkEvent *event, gpointer user_data)
event |
. |
[type GdkEventOwnerChange] |
user_data |
user data set when the signal handler was connected. |
Flags: Run First
Since: 2.6


{% extends "base.mail.html" %} {% load djmoney %} {% load i18n %} {% block content %}
{% if obj.goals.count %}
{% blocktrans context 'email' %}
Hi {{ recipient_name }},
Congratulations, your funding deadline for "{{ title }}" has passed and you've successfully reached your funding goal!
Head over to your campaign page and:


Adrienne Helms Major
Home
Fun Facts
Portfolio
Resume
Contact
Yo Adrienne!
I'm dedicated to make a difference and would love to be part of your team.
Send me a message and let me know how I can help!
Name
Email
Subject
Message
Send


Relativistic Kinetic Energy
Introduction
The work-energy theorem is a simple expression that relates the work done on a rigid body (W) to the change in kinetic energy of the body (\(\Delta K\)):
\[\begin{equation} \Delta K = W \end{equation}\]Work is defined as the path integral of force. Writing out this path integral, we arrive at an expression that should be familiar to many students in physics.
\[\begin{equation} \Delta K = W = \int_{x_i}^{x_f} \vec{F} \cdot d\vec{x} \end{equation}\]In the expression above, \(x_i\) and \(x_f\) are the initial and final positions of the rigid body. Although this expression is widely used in classical mechanics, we often forget that the work-energy theorem can be used in special relativity as well. With a bit of simple calculus, it is easy to solve for the kinetic energy of a relativistic particle using the formula above.
Relativistic Work Energy Theorem
Any work done on a point particle will change its kinetic energy - it does not matter if we are analyzing a relativistic or non-relativistic case. The only thing that changes in our analysis of kinetic energy in each case is the expression for force (\(\vec{F}\)). In the non-relativistic situation, we are familiar with Newton’s second law:
\[\begin{equation} \vec{F} = m\vec{a} \end{equation}\]Recall that this is a simplification of the impulse momentum theorem when mass is constant:
\[\begin{equation} \vec{F} = \frac{d\vec{p}}{dt} = \frac{d}{dt} \left [ m\vec{v} \right ] = \vec{v} \frac{dm}{dt} + m\frac{d\vec{v}}{dt} = m\frac{d\vec{v}}{dt} = m\vec{a} \end{equation}\]The impulse-momentum theorem can be used in the relativistic case as well. The only difference is that we will use the relativistic expression for momentum instead of the non-relativistic expression.
\[\begin{equation} \gamma = \frac{1}{\sqrt{1-(v/c)^2}} \end{equation}\] \[\begin{equation} \vec{p} = \gamma m \vec{v} \end{equation}\] \[\begin{equation} \vec{F} = \frac{d\vec{p}}{dt} = \frac{d}{dt} \left [ \gamma m \vec{v} \right ] \end{equation}\]In the expressions above, \(\gamma\) is the Lorentz factor and \(m\) is the rest mass of the particle. The velocity \(\vec{v} = \beta c\) where \(c\) is the speed of light in a vacuum and \(\beta\) is the relativistic beta of the particle. We can solve for the kinetic energy of the particle in a number of ways. I am going to integrate with respect to velocity.
The Derivation
We will orient our axes so that the velocity and force are along the x-axis. Letting \(v_x \equiv v\) and \(F_x \equiv F\) yields:
\[\begin{equation} F = \frac{dp}{dt} = \frac{d}{dt} \left [ \gamma mv \right ] \end{equation}\]Let’s plug this expression for force into the work-energy theorem and change our variable of integration to v. Since momentum and \(\gamma\) are both functions of speed, this substitution will simplify the analysis.
\[\begin{align} \Delta K &= \int_{x_i}^{x_f} \vec{F} \cdot d\vec{x}\\[0.1cm] &= \int_{x_i}^{x_f} F dx cos(0)\\[0.1cm] &= \int_{x_i}^{x_f} F dx\\[0.1cm] &= \int_{x_i}^{x_f} \frac{d}{dt} \left [ \gamma mv \right ] dx\\[0.1cm] &= \int_{t_i}^{t_f} \frac{d}{dt} \left [ \gamma mv \right ] v dt \end{align}\]Now that everything is in terms of speed \(v\) and time \(t\) we can solve this integral by using integration by parts. Just to keep the notation clear, I will use a and b instead of u and v in my expressions. Let:
\[\begin{equation} a = v \Rightarrow da = \frac{dv}{dt} dt \end{equation}\] \[\begin{equation} db = \frac{d}{dt} \left [ \gamma m v \right ] dt \Rightarrow b = \gamma mv \end{equation}\]We then get:
\[\begin{align} \Delta K &= \left [ ab \right ]_{t_i}^{t_f} - \int_{t_i}^{t_f} b da\\[0.1cm] &= \left [ \gamma m v^2 \right ]_{t_i}^{t_f} - \int_{t_i}^{t_f} \gamma mv \frac{dv}{dt} dt\\[0.1cm] &= \left [ \gamma m v^2 \right ]_{v_i}^{v_f} - \int_{v_i}^{v_f} (\gamma mv) dv\\[0.1cm] &= \left [ \frac{m v^2}{\sqrt{1-(v/c)^2}} \right ]_{v_i}^{v_f} - \int_{v_i}^{v_f} \frac{mv}{\sqrt{1-(v/c)^2}} dv \end{align}\]In the last two lines above, we use the fact that the velocity of the system is equal to \(v_i\) at time \(t_i\) and \(v_f\) at time \(t_f\). We can solve the integral above using a simple u-substituion. Let \(u = 1 - (v/c)^2\). Then, \(du = -2v dv/c^2\).
\[\begin{align} \Delta K &= \left [ \frac{m v^2}{\sqrt{1-(v/c)^2}} \right ]_{v_i}^{v_f} - \int_{v_i}^{v_f} \frac{mv}{\sqrt{1-(v/c)^2}} dv\\[0.1cm] &= \left [ \frac{m v_f^2}{\sqrt{1-(v_f/c)^2}} - \frac{m v_i^2}{\sqrt{1-(v_i/c)^2}} \right ] + \frac{mc^2}{2} \int_{1 - (v_i/c)^2}^{1-(v_f/c)^2} \frac{du}{\sqrt{u}}\\[0.1cm] &= \left [ \frac{m v_f^2}{\sqrt{1-(v_f/c)^2}} - \frac{m v_i^2}{\sqrt{1-(v_i/c)^2}} \right ] + \frac{mc^2}{2} \left [ 2\sqrt{u} \right ]_{1 - (v_i/c)^2}^{1-(v_f/c)^2}\\[0.1cm] &= \left [ \frac{m v_f^2}{\sqrt{1-(v_f/c)^2}} - \frac{m v_i^2}{\sqrt{1-(v_i/c)^2}} \right ] + mc^2 \left [ \sqrt{1-(v_f/c)^2} - \sqrt{1-(v_i/c)^2} \right ]\\[0.1cm] &= \left [ \frac{m v_f^2}{\sqrt{1-(v_f/c)^2}} - \frac{m v_i^2}{\sqrt{1-(v_i/c)^2}} \right ] + mc^2 \left [ \frac{1-(v_f/c)^2}{\sqrt{1-(v_f/c)^2}} - \frac{1-(v_i/c)^2}{\sqrt{1-(v_i/c)^2}} \right ]\\[0.1cm] &= \left [ \frac{m v_f^2}{\sqrt{1-(v_f/c)^2}} - \frac{m v_i^2}{\sqrt{1-(v_i/c)^2}} \right ] + \left [ \frac{mc^2}{\sqrt{1-(v_f/c)^2}} - \frac{m v_f^2}{\sqrt{1-(v_f/c)^2}} - \frac{mc^2}{\sqrt{1-(v_i/c)^2}} + \frac{m v_i^2}{\sqrt{1-(v_i/c)^2}} \right ]\\[0.1cm] &= \frac{mc^2}{\sqrt{1-(v_f/c)^2}} - \frac{mc^2}{\sqrt{1-(v_i/c)^2}}\\[0.1cm] &= \gamma_f mc^2 - \gamma_i mc^2\\[0.1cm] &= \left (\gamma_f - \gamma_i \right )mc^2 \end{align}\]Suppose that our particle starts from rest (or we want to use a speed of zero as a baseline). That means \(v_i = 0\) and \(\gamma_i = 1\). Thus, the final expression for the kinetic energy is:
\[\begin{equation} K_f = \left ( \gamma_f - 1 \right ) mc^2 \end{equation}\]I plot the kinetic energy of a particle with mass m = 1 kg at different values of \(\beta\) in the graph below. Note that the kinetic energy of the moving particle is completely determined by its rest mass and the Lorentz factor (along with a couple of constants). As \(\beta \rightarrow 1\) (i.e. the speed of the particle approaches the speed of light) the energy tends to infinity.
The Low Speed Limit
In a previous blog post I showed how one can expand the Lorentz factor, drop higher order terms, and retrieve the low-speed limit of relativistic expressions. Why don’t we do that here? Recall that the expansion for \(\gamma\) is given by:
\[\begin{equation} \gamma = 1 + \frac{1}{2}\beta^2 + \frac{3}{8}\beta^4 + \frac{5}{16}\beta^6 + \frac{35}{128}\beta^8 + \dots \end{equation}\]Substitute that into our expression for kinetic energy.
\[\begin{equation} K_f = \left ( \frac{1}{2}\beta_f^2 + \frac{3}{8}\beta_f^4 + \frac{5}{16}\beta_f^6 + \frac{35}{128}\beta_f^8 + \dots \right ) mc^2 \end{equation}\]Drop all terms of \(\beta_f^3\) or higher.
\[\begin{equation} K_f \approx \frac{1}{2}\beta^2 mc^2 = \frac{1}{2}mv^2 \end{equation}\]That looks familiar. We got the classical, non-relativistic kinetic energy when we took the low speed limit. Everything is self-consistent! In the figure below, I plot the non-relativistic and relativistic calculations for kinetic energy at different values of \(\beta\). Notice that at low speeds, they match up pretty well. But when \(\beta\) starts to increase, the non-relativistic kinetic energy is way off from the correct relativistic kinetic energy.
Conclusion
Whenever we break into a new area of physics, we need to remember that our previous knowledge is still valid. Here, we used a simple classical concept to derive the relativistic kinetic energy of a particle.
Until next week!


Art Poster
College . Typography . InDesign
The purpose of this typography project was to organize the information into a readable format for the viewer. I broke the information into categories and then organized it by event date. From there I used type families, typeface, and color to break up the rest of the information.


MathJax $V^3$ with $svg$ output on the page as well as plotly graphs
no MathJax: Apple: $2, Orange: $3