Copyright © 2011 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document lists the design goals and requirements that specifications would need to address in order to standardize various aspects of widgets. A Widget is an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine or mobile device. Typical examples of widgets include clocks, CPU gauges, sticky notes, battery-life indicators, games, and widgets that make use of Web services, like weather forecasters, news readers, e-mail checkers, photo albums, and currency converters.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document reflects three years of gathering and refining requirements for the Widget family of specifications. The requirements were gathered by extensive consultation with W3C members and the public, via the Working Group's mailing lists (WAF archive, WebApps archive). The Working Group's goal is to make sure that vendor's requirements for Widgets are complete and have been effectively captured. The Widget family of specifications will set out to address as many requirements as possible (particularly the ones marked with the keywords must and should).
This document is produced by the Web Applications (WebApps) Working Group (WG). This WG is part of the Rich Web Clients Activity and this activity is within the W3C's Interaction Domain. The public is encouraged to send comments to the WebApps Working Group's public mailing list<EMAIL_ADDRESS>(archive). See W3C mailing list and archive usage guidelines.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
A widget is an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine or mobile device. A widget may run as a stand-alone application (meaning it can run outside of a Web browser), and it is envisioned that the kind of widgets being standardized by this effort will one day be embedded into Web documents.
In this document, the runtime environment in which a widget is run is referred to as a widget user agent. Note that running widgets may be the specific purpose of a widget user agent, or it may be a mode of operation of a more generic user agent (e.g. a Web browser). A widget running on a widget user agent is referred to as an instantiated widget. Prior to instantiation, a widget exists as a widget package.
Prior to this standardization effort, there was no standardized way to author, package, digitally sign, or internationalize a widget package for distribution and deployment on the Web. In the widget space, although many widget user agents are now on the market, widgets built for one widget user agent (e.g., Windows 8 Metro applications) are still not able to run on any other widget user agent (Apple's Dashboard). This document, along with the Widget family of specifications, attempt to address the interoperability issues.
This document lists the design goals and requirements that specifications need to address in order to standardize how widgets are authored/scripted, digitally signed, secured, packaged and deployed in a way that is device independent, follows W3C principles, and is as interoperable as possible with existing market-leading user agents and existing Web browsers.
To be clear, this specification describes the requirements for installable/desktop or mobile widgets (akin to Apple's Dashboard, Opera Widgets, Windows 8's Metro Applications). This document does not address the requirements of "web widgets", such as iGoogle Gadgets or Windows Live Gadgets, which are being specified by the Open Ajax Alliance's IDE Working Group.
This section is normative.
The key words MUST, MUST NOT, required, not required, SHOULD, should not, recommended, MAY, and optional in the normative parts of this document are to be interpreted as described in RFC2119.
This specification only applies to one class of product: W3C Technical Reports. The Working Group will attempt to standardize widgets by addressing the requirements listed in this document through the Widget family of specifications, which include:
Only normative statements marked with the keywords MUST and SHOULD are required to be standardized by the Widget family of specifications. The Working Group will publish an informative Working Group Note at the end of the standardization process listing any requirements that were not formally addressed by the Widget family of specifications.
Although a number of specifications will be created to address the requirements enumerated in this document, in some instances, it will be the amalgamation of multiple parts of individual specifications that address a single requirement. Nevertheless, this document speaks only of a conforming specification (defined below). The Working Group's choice to have multiple specifications address the following requirements, as opposed to having a monolithic specification, was made for the following reasons:
A conforming specification is one that addresses one or more requirements
listed in this document. A conforming specification SHOULD attempt to
address requirements marked with the keywords should
or
may
unless there is a technically valid reason not to do so.
The validity of technical reasons for not addressing any requirements will be determined
by the Working Group members, and through communication with vendors and the public on the
Working Group's public mailing list<EMAIL_ADDRESS>(archive).
This section is informative.
This section lists the design goals that the Working Group recommends a conforming specification adopt when attempting to standardize the various standardizable aspects of widgets. The requirements are directly motivated by the following design goals. The design goals are listed in alphabetical order.
A conforming specification needs to support relevant accessibility guidelines, such as WCAG 2.0.
A conforming specification needs to maintain compatibility with, or directly make use of, other standards where possible.
A conforming specification needs to consider the development practices currently used by widget developers and promote relevant industry best-practice, such as MWBP.
A conforming specification needs to support relevant device independence guidelines.
A conforming specification needs to specify solutions that are easy to use and avoid unnecessary complexity, meaning that a widget package should be easy for authors to create without requiring special or expensive proprietary software, and easy for end-users to acquire and install/run.
A conforming specification needs to implement relevant internationalization and localization guidelines, such as i18n-XML and BCP 47, as well as consider current practical internationalization solutions used by the widget development community.
A conforming specification needs to attempt to be as interoperable as possible with existing market-leading widget user agents.
A conforming specification needs to be specified in such a way that it ensures that a
widget package can still be processed well into the future (e.g. 100 years from the date
the specification reaches Recommendation Status as defined in the
W3C
Process document).
A conforming specification needs to address the security concerns of end-users, authors, distributors and device manufacturers by recommending appropriate security policies and programming behavior. A conforming specification must also consider the distribution and deployment security requirements as they relate to authors and vendors.
A conforming specification needs to deal with cases where an end-user acquires a widget package over HTTP or via some other non HTTP-based (offline) means, such as a local file system, Blue tooth or a Multimedia Message Service. In addition, a conforming specification needs to provide a means by which widgets can be updated when a new or different version of a widget becomes available. It must be possible to perform updates from online and offline sources.
Any new technologies or processes defined by a conforming specification needs to designed in such a way that they are beneficial the wider Web community at large. In other words, conforming specifications should try not to be insular to their problem domain, but should also consider the needs of the wider Web community.
This section is normative.
This section enumerates the requirements that a conforming specification would need to address to standardize widgets. These requirements are directly motivated by the design goals and are based on an iterative process of feedback from the public, discussions with various vendors, and a survey of market-leading widget user agents.
This section enumerates the requirements that a conforming specification needs to address to standardize the packaging format of a widget. The objective of this section is to ensure that a conforming specification recommends a general packaging format that is, amongst other things:
A conforming specification MUST recommend a packaging format that is royalty free, open, and widely implemented across market-leading widget user agents and compatible with mobile devices. In addition, a conforming specification MUST specify exactly which aspects of the packaging format are to be supported by conforming widget user agents.
A conforming specification MUST recommend that a conforming widget package be sent over HTTP with a formally registered media type that is specific to the Widget family of specifications. The Working Group MUST formally register the media type with the Internet Assigned Numbers Authority (IANA). A conforming specification MUST specify how a widget user agent will process a widget package that was served with an unsupported media type or when the media type is unspecified.
A conforming specification MUST specify a file extension that authors MAY assign to widget packages in contexts that rely on file extensions to indicate the content type, such is the case on many popular file systems.
A conforming specification MUST recommend a packaging format that supports structuring resources into collections such as files and directories (understood in this document in a broader sense than in some popular file systems, namely as forms of generic logical containers). In addition, the packaging format SHOULD allow authors to add and remove resources of a widget package without needing to recreate the widget package.
A conforming specification MUST indicate if any resources (files or directories or similar logical containers) are mandatory or reserved and what specific function they serve in the widget package. A conforming specification SHOULD specify graceful error handling/recovery procedures if those resources are used erroneously or missing.
resources
' directory located at the root of the widget package.A conforming specification MUST recommend a hierarchical addressing scheme that can be used to address the individual resources within a widget package from within a configuration document. The hierarchical addressing scheme MUST be capable of expressing both absolute and relative relationships between a resource and the widget package. In addition, the hierarchical addressing scheme MUST be interoperable with resources that might also need to address other resources within the widget package (e.g., HTML documents, CSS documents, JavaScript documents, etc.). The hierarchical addressing scheme SHOULD be one that Web authors would feel comfortable using or to which they are already accustomed.
<icon src="icons/cat.ico'/>
). Or, for example, addressing an image within a widget package from within a HTML start file (e.g. <img src="/backgrounds/sky.png'>
). A conforming specification MUST recommend a packaging format that allows for non-ASCII characters in file and directory names, allowing authors to create widgets suitable for various cultures and languages, as well as multilingual contexts. The packaging format MUST either provide some means to declare the character encoding or specify what the character encoding is. The UTF-8 character encoding SHOULD be either the default (if multiple encodings are allowed) or sole encoding used.
A conforming specification MUST provide guidelines that explain to authors how collections of resources need to be structured for the purpose of internationalization.
'resources/en/
' for
all English content, and 'resources/en-AU/
' for further localized
Australian-English content, and so on).A conforming specification SHOULD specify a processing model that automatically localizes content when authors follow the localization guidelines.
A conforming specification MUST recommend a packaging format that is suitable for delivery on many devices, particularly Web-enabled mobile devices.
A conforming specification MUST recommend a packaging format that supports both decompressed data and OPTIONAL data compression. A conforming specification SHOULD also recommend at least one royalty-free default compression/decompression algorithm that is compatible with market-leading widget user agents and implementations of the packaging format on mobile devices.
In the case that the packaging format does not support labeling resources with a media type, a conforming specification MUST either specify or recommend a means of deriving the media type of resources for the purposes of rendering. A conforming specification MAY define a means to override how a widget user agent derives the media type of a resource (e.g., treat resources with the file extension .php
as text/html
), but MUST NOT force a widget user agent to process resources of one media type as that of another type (e.g. treating a jpeg image at text/html
).
.html
file extension as text/htm
l (and not as application/xhtml+xml
).This section enumerates the requirements that a conforming specification needs to address in order to standardize the configuration document. The objective of this section is to ensure that a conforming specification specifies a configuration document format that defines:
A conforming specification MUST specify the configuration document language using a common data interchange format, as well as the rules for processing the configuration document language and any micro-syntaxes represented as character data. A conforming specification MUST specify graceful error handling procedures for when metadata values are in error, or the values are impossible to satisfy or realize by the user agent. The metadata MUST be extractable, processable and reusable in other contexts (for instance, to create an online gallery of widgets). In addition, a conforming specification SHOULD make it clear to authors which elements are optional and which elements are mandatory. A conforming specification SHOULD specify a formal schema for the language, as well as define any configuration defaults. The schema SHOULD NOT be a normative part of the conforming specification, but MUST be suitable for use by conformance checkers. A conforming specification MUST recommend that configuration documents be encoded in UTF-8. A conforming specification MAY specify the configuration document language using alternative standardized data interchange formats (e.g. JSON) and schema.
A conforming specification MUST specify the structure and semantics of elements that represent metadata about a widget. More specifically, a conforming specification MUST specify the structure and semantics of elements that represent data about the widget, including the name, version number, a unique identifier, and a description of what a widget does.
A conforming specification MUST specify the structure and semantics data about the authorship of a widget, including an author's name, e-mail, and organization.
A conforming specification MUST specify the structure and semantics of fields that explicitly reference, or otherwise include, a software license agreement or notice. In addition, a conforming specification MUST provide a means to declare who holds the copyright for the widget, as well as a model for how this data must be processed by a widget user agent.
For widgets that make use of a rendering context, a conforming specification SHOULD specify an OPTIONAL means for an author to declare the initial visual dimensions for an instantiated widget in a way that is device independent (e.g. via CSS pixels). In the absence of user style sheets, a conforming specification MUST specify that styling by the author takes precedence over dimensional values declared in the configuration document or any dimensional values implicitly computed by the widget user agent. However, in the presence of user style sheets, user style sheets take precedence but MUST be applied in conformance to the cascade model and rules of behavior specified in CSS.
/ui/clock.svg
'). Alternatively, the resource might be a HTML document
that when combined with the visual rendering dimensions requirement displays
at the appropriate size.A conforming specification Should specify an automated model for finding the start file of the widget in the absence of a declarative bootstrap. The automated bootstrap model MUST NOT be able to address resources outside the scope of the widget package and MUST NOT address resources on the Web over HTTP or any other protocol. The widget user agent SHOULD be allowed to select its preferred format for the start file, and then it SHOULD locate that resource first before attempting to locate other resources.
index.htm
, index.html
,
index.svg
, etc.) firstly within localized directory names, as required by
automatic localization, and then within the directories of the widget package. If that
search fails, then the widget user agent could try to find files with extensions ".html,
.svg, etc." starting from the root directory.A conforming specification MUST specify a means to declare iconic representations of the widget for use as alternate or fallback content, standby indicator or in a non-running context. The conforming specification should not limit iconic representations to static images and it SHOULD provide support for alternative text representations of an icon where possible. A conforming specification SHOULD also recommend a default icon media type and file name.
A conforming specification MUST specify a means to for authors to declare values of custom and predefined configuration parameters, all of which would be applied as a widget is instantiated. A conforming specification MUST specify the default values for specification-defined parameters in case a parameter is missing or the value supplied by the author is invalid. A conforming specification SHOULD allow a widget user agent to override author defined parameters in circumstances where it might be beneficial for users or has the potential to improve performance or stability of the widget user agent.
width
= 50
indicating
the 50
as the value for visual width. Or, in the absence of an
author-declared width, the widget user agent will automatically set the width
to some standardized value (e.g. 300
).A conforming specification MUST specify a means to for authors to declare persistently stored name-values pairs that an author MAY use to configure a widget instance when the widget is first run. A conforming specification MUST allow authors to define which values are read only, meaning that those values MUST be protected from modification at runtime. A conforming specification MUST specify that these values MUST be made available to the author at runtime via scripting.
A conforming specification MUST specify or recommend a means to allow authors to declare that an instantiated widget will require access to formally standardized features that allow access to device-specific capabilities or proprietary features (e.g. a proprietary API to access the camera on a device). A conforming specification MAY be specified in such a way that fallback relationships can be declared so that if one feature is unavailable, another can be declared as a possible substitute. In addition, a conforming specification MUST provide authors with a means of stating which features are optional and which features are mandatory for a widget to run.
A conforming specification MUST specify the configuration document format in such a way that it can be used independently of the widget package that contains it. A conforming specification MAY provide guidelines for how the configuration document can be used separately from a widget package.
A conforming specification MUST provide a means for author to indicate at least one preferred display mode for a widget. In the absence of a preferred mode, a conforming specification SHOULD provide a consistent default display mode across all user agents. A conforming specification SHOULD make it possible for an author to indicate to the widget user agent which display modes the widget has been designed to run in. The Widget User Agent MAY ignore the indications of display mode supported, but SHOULD NOT ignore the preferred display mode.
This section enumerates the requirements that a conforming specification needs to address to standardize an API for widgets. The objective of this section is to ensure that a conforming specification specifies an API that allows authors to, amongst other things:
A conforming specification MUST specify a set of interfaces that expose properties, methods, and events of an instantiated widget. These interfaces MUST be encapsulated as a self-contained object, or some similar data structure, in a non-object-oriented programming environment.
widget
Object described in the Dashboard Reference
and Microsoft's System.Gadget
Object described in the Sidebar
Reference.A conforming specification MUST specify the APIs in this section in a standardized interface definition language (e.g. Web IDL).
A conforming specification SHOULD specify a set of interfaces that expose relevant properties and methods of the widget user agent.
A conforming specification MUST specify or recommend a set of interfaces for dynamically getting and setting persistently stored values for a widget instance set using the means provided by the author-defined start-up values. A widget user agent MUST persistently retain a widget's author-defined start-up values in the case where a widget is re-instantiated or the widget user agent is restarted. A conforming specification MUST recommend an API that allows authors to iterate and modify the author-defined start-up values that are not set to read-only, clear the values, add new values, get all the names of the values, and get the number of values currently stored. A conforming specification MUST specify that, if an author attempts to modify a value that is set as read-only, the API throw an appropriate access violation exception.
A conforming specification must define a set of states in the lifecycle of the instantiated widget as well as how and when an instantiated widget enters each state. Changes in states must have associated events which can be consumed by event handlers, such as scripts. Additionally the API MUST expose the current state. A conforming specification MUST NOT require the widget user agent to send events to the widget immediately, and should allow the widget user agent to dispatch the events at its convenience.
A conforming specification MUST specify a means that allows authors to check if a widget instance is connected to the network. A conforming specification MUST define the scope of the term "network" and MUST specify a means by which connection and disconnection events can be captured by an author through script. A conforming specification MUST NOT guarantee event delivery, as there may be cases where a device is running low on resources (e.g., power) and can not afford to deliver them.
A conforming specification SHOULD specify how an instantiated widget (or any of its presentation contexts) should classify itself to the widget user agent as critical, floating, output-only, etc.. Some of these mode changes may require the end-user's attention, in which a case conforming specification SHOULD recommend that widget user agent find a suitable way to draw the end-user's attention.
A conforming specification SHOULD specify a mechanism, either through an API or through the configuration document, which allows instantiated widgets to bind to third-party APIs that allow access to device-specific resources and services. A conforming specification is not required to specify any APIs to device specific resources or services, but SHOULD provide some means of binding to those APIs if they are available and the user agrees. A conforming specification SHOULD specify that bindings MUST NOT occur without consulting the user or a policy which exists to represent the end user (or the owner of the device).
A conforming specification SHOULD specify a means that allows authors to access data they declared in the configuration document for the widget package.
A conforming specification SHOULD specify a means that allows authors to open IRIs in an appropriate scheme handler (e.g., using the default Web Browser to open HTTP URIs).
A conforming specification MUST define a mechanism to set the base URI for any DOM instances that occur within the Widget, and it MUST define a mechanism that enables the construction of URI references between different resources within a widget package.
<img
src="images/bg.png'/>
where the src
attribute
resolves to something similar to
"widget://engine/myWidget.wgt/images/bg.png
" or "http://localhost/myWidget.wgt/images/bg.png
").A conforming specification MUST specify an API to allow authors to programmatically switch between display modes. A conforming user agent MUST be allowed to ignore requests by the author to switch to an unsupported display mode, but MUST throw an exception or error if it will not perform the mode change. A conforming specification MUST also provide a guaranteed means for authors to detect a change in display mode. A conforming specification MUST provide a means for an author to check the current display mode of a widget.
This section enumerates the requirements that a conforming specification needs to address in order to standardize a user experience widgets. The objective of this section is to ensure that a conforming specification make recommendations that would make widgets accessible and able to be rendered on a range of devices.
A conforming specification MUST specify that the language used to declare the user interface of a widget be a language that is accessible at the various levels specified by the WCAG 2.0 (perceivable, operable, understandable, and robust): specifically, the language MUST provide keyboard access to interactive graphical elements, and provide means to access the widget's functionality through a non-graphical UI. For the user interface language, the role and state of all interface elements MUST be available to screen readers and other assistive technologies, to allow relevant sections of text and functionality to be accessed.
A conforming specification MUST specify a set of display modes for widgets that stipulate how widgets SHOULD be rendered at runtime when in a specific mode. A conforming specification SHOULD also define particular allowed, or disallowed, user-interaction behaviors for each display mode; such as the ability for a widget to be dragged or re-sized. For each display mode, the way in which the widget is displayed MUST be specified so that the rendering of the Widget is as consistent as possible across widget user agents. The display modes SHOULD also be specified to interoperate with device independence best practices and/or specifications. Proprietary display modes MAY be supported by the Widget User Agent.
This section enumerates the requirements that a conforming specification needs to address in order to standardize certain aspects of widget user agents. The objective of this section is to ensure that a conforming specification recommends features that will make widget user agents interoperate more effectively with each other and with services on the Web.
A conforming specification MUST specify a model to allow widget user agents to check if a new version of a widget package has become available online or from local storage. A conforming specification MUST recommend that an updated widget is downloaded only with the user's consent and that users be able to cancel or defer updates. An automatic update MUST preserve the identity of a widget, meaning that that preferences previously set by the user are retained after the update process. A conforming specification SHOULD recommend that, when possible, updates be conducted over a secure communication channel. In addition, a conforming specification SHOULD specify a means for updates to be authenticated. A conforming specification SHOULD also define a mechanism to protect against downgrade attacks using ancient versions of widgets. A conforming specification SHOULD specify that signature verification policies be applied to updates in a manner that is consistent with those applied upon original installation of the widget.
A conforming specification MUST recommend that a widget user agent allow multiple instances of a widget package to be instantiated. A conforming specification MAY recommend that implementations which have sufficient resources (CPU, memory, etc.) run widgets concurrently as separate processes.
A conforming specification MUST allow a widget user agent to dynamically change display mode of a widget. Switching from one mode to another, however, MUST not cause the re-instantiation of the Widget. Furthermore, it MUST be possible for a Widget to seamlessly move between modes, maintaining runtime state and any processes that are in progress.
This section enumerates the requirements that a conforming specification needs to address in order to standardize industry standard signing and an adequate security model for widgets. The objective of this section is to ensure that a conforming specification specifies a security model that:
A conforming specification MUST specify runtime exceptions for when a widget's script attempts to perform an action it's not authorized to perform.
A conforming specification MUST specify a means to verify the authenticity and data integrity of all resources in a widget package, with the exception of any resources explicitly excluded by the specification (e.g. the digital signature file itself). A conforming specification MUST provide these capabilities by specifying or recommending a processing model for generating and verifying a digital signature associated with a widget package. The digital signature scheme MUST be compatible with existing Public Key Infrastructures (PKI), particularly X.509v3.
A conforming specification SHOULD recommend that it should be possible for a widget package to contain multiple independent digital signatures (i.e. it be possible to include multiple signatures and associated certificate chains). A conforming specification MUST specify the expected behavior when multiple signatures and certificate chains are provided. A conforming specification MUST specify that if none of the signatures and certificate chains can be verified, e.g. because of missing root certificates or where any certificates in the chain have expired or are not yet valid, then the widget package SHOULD be treated as unsigned (meaning that widget is treated as if it had no digital signature).
A conforming specification MUST recommend a digital signature format that can be extracted and conveyed independently of the widget package. A conforming specification SHOULD provide guidelines for how any digital signature can be used separately from a widget package. An example of such use is to perform certificate chain validation and other checks related to the signature key information, without necessarily validating the referenced widget content at that time. Risks associated with separating time of verification and validation steps MAY need consideration.
A conforming specification MUST specify at least one mandatory to support message digest algorithm. A conforming specification SHOULD recommend that other message digest algorithms may be supported.
A conforming specification MUST recommend that where a widget package is digitally signed, it MUST be possible to select from multiple message signature algorithms. A conforming specification MUST mandate that at least one signature algorithm be supported by a widget user agent.
A conforming specification MUST recommend that widget user agents support processing signatures with key lengths of 2048 bits or greater. A conforming specification MUST recommend to authors that widget packages be signed with key lengths of 2048 bits or greater.
A conforming specification MUST specify the expected use of valid key usage extensions
and when present (in end entity certificates) MUST specify that implementations verify
that the extension has the digitalSignature
bit set (as defined in X.509v3). A conforming
specification MUST specify that implementations recognize the extended key usage
extension and when present (in end entity certificates) verify that the extension
contains the id-kp-codeSigning
object identifier.
A conforming specification SHOULD specify a means of packaging up-to-date revocation information with a digital signature and associated certificate chain (e.g. a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) response stating that certificate has not been revoked). In addition, a conforming specification SHOULD specify the behavior in the case that the revocation information is not included or not complete. A conforming specification SHOULD specify that if the revocation information is present the widget processing environment MUST attempt to verify the revocation information. A conforming specification SHOULD specify the behavior if revocation information is out of date or otherwise invalid.
A conforming specification MUST specify a default security policy that limits the privileges afforded to a widget at runtime. The default security policy MUST be specified in such a way that it forces a widget package to explicitly request permission to use particular device capabilities (see also the Security Declarations requirement).
A conforming specification MAY specify a mechanism that allows a remote trusted authority to update black and/or white lists and the security policy related to widget packages installed on the widget user agent.
A conforming specification MUST specify or recommend a means for declaring that an instantiated widget will require access to resources or services that have to the potential to introduce a security risk for an end user. A conforming specification SHOULD also make it possible to externalize and associate security declarations with a particular widget package (e.g., by allowing security declarations to be securely acquired from an external trusted authority over HTTP). This MUST include a means of declaring the APIs that a widget expects to access. When possible, a conforming specification MUST specify a means to verify the authenticity and integrity of security declarations included in the widget package (e.g. by using Digital Signatures).
The editor would like to thank to the following people who have reviewed or otherwise contributed to this document (ordered by first name):
Alexander Dreiling, Anne van Kesteren, Arthur Barstow, Arun Ranganathan, Bárbara Barbosa Neves Benoit Suzanne, Bert Bos, Bradford Lassey, Bryan Sullivan, Cameron McCormack, Charles McCathieNevile, Cliff Schmidt, Claudio Venezia, Coach Wei, Corin Edwards, Cynthia Shelly, Cyril Concolato, Dan Brickley, David Pollington, David Rogers, Dean Jackson, Doug Schepers, Ed Voas, Gene Vayngrib,Guido Grassel, Jay Sweeney, Jim Ley, Jon Ferraiolo, Jose Manuel Cantera Fonseca, Josh Soref, Kevin Lawver, Krzysztof Maczyński, Lachlan Hunt, Mark Baker, Marc Silbey, Mikko Pohja, Michael Smith, Nick Allott, Olli immonen, Paddy Byers, Philipp Heltewig, Richard Tibbett, Sally Cain, Sean Mullan, Stephen Paul Weber, Steven Faulkner, Thomas Landspurg, Yang Wong, Zachary Fitz-Walter.


Use this page to configure capture points to facilitate debugging of asynchronous code.
A capture point is a place in your code where the debugger captures stack traces to be used later when you reach a
specific point in the code (the insertion point) and want to see how you got there. IntelliJ IDEA does this by
substituting part of the call stack with a captured stack.
Asynchronous stack traces are enabled by default. To disable them, deselect the Instrumenting agent (requires debugger restart)
option. The most common capture points are built-in, so no configuration is required.
If you need to use capture points that are not included in the default configuration, you can use the
Async.Schedule
and Async.Execute
annotations that reside in the public JetBrains annotations
package and can be referenced in your code. To use them, add this Maven repository as a dependency for your
artifacts.
(If, for some reason, you do not want to use the Maven repository, you can simply copy these annotations and add
them as classes to your project.)
If you cannot use annotations or need to be able to capture local variables, you can configure capture points
manually by using the following controls:
(You can download some additional capture settings from the following repository: IntelliJ IDEA debugger Capture Points.)


Let’s talk about your project
Ready to take it to the next level? Contact us today and find out how our expertise can help your business grow.
Get in touch
Our mobile designs bring intuitive digital solutions to your customers right at their fingertips.
Ready to take it to the next level? Contact us today and find out how our expertise can help your business grow.


products/fiddleleaf
Fiddle Leaf
$35
The Fiddle Leaf Fig is famous for its broad, vibrant green leaves with prominent veining. It prefers a stable environment and can be fickle when temps fluctuate. Keep it in bright light, and water about once every 1–2 weeks.


|
||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
| Interface Summary | |
|---|---|
| FeatureI | A feature on a sequence (for example, an exon or a gene), defined by a location and a set of attributes encoded as key/value pairs. |
| SeqI | A sequence of either nucleotides or amino acids. |
| Class Summary | |
|---|---|
| AminoAcid | An amino acid object with codon/residue utility methods. |
| Feature | A Feature corresponds to a single row in a GFF file. |
| FeatureList | A list of FeatureI objects implemented using a Java ArrayList; corresponds to a GFF file. |
| Location | A location on a sequence. |
| LocIterator | Move a sliding window over a Location. |
| Nucleotide | A nucleotide object, with Dna/Rna utility methods. |
| SeqBig | A SeqI implementation capable of handling large sequences that do not fit into memory. |
| SeqFast | A SeqI implementation that keeps the entire sequence in memory. |
| SeqStranded | A SeqI wrapper that presents a stranded coordinate system mapped to an underlying SeqI object. |
| Enum Summary | |
|---|---|
| Nucleotide.Type | Sequence type: DNA or RNA. |
Sequences, features on sequences, and the locations of features.
|
||||||||
| PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |


Home
/
Create Run
/
UI
Json
Run
Run Name
Business Unit
Team
Description
Add Loadpart
Add Monitoring Agent
Add Loadpart
LoadPart Name
×
Agents
Log Level
Add Monitoring Agent
Loadpart
Loadpart Name
Agents
Log Level
Add Input Resource Files
Data Generators
Add Data Generator
Name
Type
×
Input Details
Start Value
Max Value
Jump
Value
Maximum Value
Add To List
Type
Length
Closed String
Add To List
Add To List
Add Distribution Map
Start
End
Value
Add Group
Delete
Group Details
Group Name
Group Start Delay
Thread Start Delay
Throughput
Repeats
Duration
Threads
Data Generators
Add Data Generator
Name
Type
×
Input Details
Start Value
Max Value
Jump
Value
Maximum Value
Add To List
Type
Length
Closed String
Add To List
Add To List
Add Distribution Map
Start
End
Value
Add Function
Function
Function Name
Function Class
Input Parameters
Delete
Group Details
Group Name
Group Start Delay
Thread Start Delay
Throughput
Repeats
Duration
Threads
Warm Up Repeats
Add Group Dependency
Data Generators
Add Data Generator
Name
Type
×
Input Details
Start Value
Max Value
Jump
Value
Maximum Value
Add To List
Type
Length
Closed String
Add To List
Add To List
Add Distribution Map
Start
End
Value
Add Group Timers
Add Timer
Timer Name
×
Duration
Threads
Throughput
Add Function
Delete
Function
Function Name
Function Class
Dump Data
Input Parameters
Custom Timers
Custom Histograms
Custom Counters
Delete
Group Details
Group Name
Group Start Delay
Thread Start Delay
Throughput
Repeats
Duration
Threads
Data Generators
Add Data Generator
Name
Type
×
Input Details
Start Value
Max Value
Jump
Value
Maximum Value
Add To List
Type
Length
Closed String
Add To List
Add To List
Add Distribution Map
Start
End
Value
Add Function
Function
Function Name
Function Class
Input Parameters
Delete
Monitoring Agent
Monitor Resources
On Demand Monitor Resources
Add On Demand Collector
Collector Name
×
Collector
Interval
Collector Parameters
Delete
Update
Execute
×
Delete Run
Are you sure, you want to delete the run??


{% extends "layout.html" %} {% block page_title %} About - GOV.UK Prototype kit {% endblock %} {% block content %} Universal Credit Switch Find out when you need to switch to Universal Credit and what you need to prepare for it. Start {% endblock %}
Find out when you need to switch to Universal Credit and what you need to prepare for it.
Start


VMware Carbon Black Cloud Extension
A window into Carbon Black from Chrome
About
v0.3
This is a non-official integration with VMware Carbon Black Cloud. For more information check out the
Github
repo. This integration is not affiliated with VMware or VMware Carbon Black.
Configuration
Carbon Black Cloud URL
Valid Carbon Black Cloud URL required
Organizaton Key
Valid organization key is required.
Custom API ID
Valid API ID required.
Custom API Key
Valid API key required.
Save Configuration


|
The Encog Project | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object org.encog.engine.opencl.EncogCLItem org.encog.engine.opencl.EncogCLDevice
public class EncogCLDevice
An OpenCL compute device. One of these will be created for each GPU on your system. Some GPU drivers will also map your CPU as a compute device. A device will likely have parallel processing capabilities. A CPU device will have multiple cores. A GPU, will have multiple compute units. Devices are held by Platforms. A platform is a way to group all devices from a single vendor or driver.
| Constructor Summary | |
|---|---|
EncogCLDevice(EncogCLPlatform platform,
org.jocl.cl_device_id device)
Construct an OpenCL device. |
| Method Summary | |
|---|---|
org.jocl.cl_device_id |
getDevice()
|
long |
getDeviceLong(int param)
Get a long param from the device. |
java.lang.String |
getDeviceString(int param)
Get a config string from the device. |
long |
getGlobalMemorySize()
|
long |
getLocalMemorySize()
|
long |
getMaxClockFrequency()
|
long |
getMaxComputeUnits()
|
long |
getMaxWorkGroupSize()
|
EncogCLPlatform |
getPlatform()
|
EncogCLQueue |
getQueue()
|
boolean |
isCPU()
|
java.lang.String |
toString()
|
| Methods inherited from class org.encog.engine.opencl.EncogCLItem |
|---|
getName, getVender, isEnabled, setEnabled, setName, setVender |
| Methods inherited from class java.lang.Object |
|---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait |
| Constructor Detail |
|---|
public EncogCLDevice(EncogCLPlatform platform, org.jocl.cl_device_id device)
platform
- The platform.device
- The device.| Method Detail |
|---|
public org.jocl.cl_device_id getDevice()
public long getDeviceLong(int param)
param
- The param desired.
public java.lang.String getDeviceString(int param)
param
- The param to get.
public long getGlobalMemorySize()
public long getLocalMemorySize()
public long getMaxClockFrequency()
public long getMaxComputeUnits()
public long getMaxWorkGroupSize()
public EncogCLPlatform getPlatform()
public EncogCLQueue getQueue()
public boolean isCPU()
public java.lang.String toString()
toString
in class java.lang.Object
|
The Encog Project | ||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


{{ template "chrome/header.html" . }}
Whoops! It looks like the page you are looking for can't be found, sorry about that!
If you think this is something we should know about, please contact us.


{% for raw in bokeh.css_raw %} {% endfor %}
{# start CONTENT BLOCK #} {# bk-bs is bokeh's namespacing of normal bootstrap classes #}This spectrogram demo uses PyAudio to sample the computer's microphone, NumPy to compute the FFT and power spectrum of the samples, Bokeh to create embeddable plots and widgets to display and interact with the data, and a simple Flask application to serve up the single page app written in CoffeeScript. The complete source code can be found in the Bokeh GitHub repository here.


|
SmartFactory_SorticRoboter_MQTTCommunication
|
If the client is used to subscribe to topics, a callback function must be provided in the constructor. his function is called when new messages arrive at the client. More...
#include <MQTTCommunication.h>
Public Member Functions | |
| Communication () | |
| Communication (String Hostname, void(*callbackFPtr)(char *, unsigned char *, unsigned int)) | |
| Construct a new Communication object. More... | |
| void | init () |
| Initializes the Hard- and Software for WLAN and MQTT-Connection. More... | |
| bool | loop () |
| This should be called regularly to allow the client to process incoming messages and maintain its connection to the server. More... | |
| void | printNetworkInfo () |
| bool | subscribe (const String topic) |
| subsribes to MQTT topic on Server More... | |
| bool | unsubscribe (const String topic) |
| unsubsribes from MQTT topic on Server More... | |
| bool | publishMessage (const String topic, const String msg) |
| handles outgoing MQTT messages to Server More... | |
Private Attributes | |
| String | pHostname |
| WiFiClient | pClient = WiFiClient() |
| instance of WiFiClient More... | |
| Network | pNetwork |
| instance of Network More... | |
| myMQTT | pMymqtt |
| instance of myMQTT More... | |
| void(* | funcPointer )(char *, unsigned char *, unsigned int) = nullptr |
| functionpointer to callback-function More... | |
If the client is used to subscribe to topics, a callback function must be provided in the constructor. his function is called when new messages arrive at the client.
Internally, the client uses the same buffer for both inbound and outbound messages. After the callback function returns, or if a call to either publish or subscribe is made from within the callback function, the topic and payload values passed to the function will be overwritten. The application should create its own copy of the values if they are required beyond this.
https://pubsubclient.knolleary.net/api.html#callback
This Function is global because you need to access it from a diffrent class and pass it as pointer. This would be possible if it's static but then all function which get called in callback need to be static too.
| topic | - the topic the message arrived on (const char[]) |
| payload | - the message payload (byte array) |
| length | - the length of the message payload (unsigned int) |
The Connection-class provides the interface
|
inline |
| Communication::Communication | ( | String | Hostname, |
| void(*)(char *, unsigned char *, unsigned int) | callbackFPtr | ||
| ) |
|
inline |
Initializes the Hard- and Software for WLAN and MQTT-Connection.
|
inline |
This should be called regularly to allow the client to process incoming messages and maintain its connection to the server.
|
inline |
|
inline |
handles outgoing MQTT messages to Server
Checks if the Board is connected to a newtork and reconects if not
Beware though that the default packet size supported by the PubSub client is 128 bytes. You can increase this limit by editing the value lof MQTT_MAX_PACKET_SIZE in PubSubClient.h
| topic | - the topic to publish to (const char[]) |
| msg | - the message to publish (const char[]) |
|
inline |
subsribes to MQTT topic on Server
Checks if the Board is connected to a newtork and reconects if not Check if the client is connected to the server if not call connectToMQTT()
| topic | - the topic to subscribe to (const char[]) |
|
inline |
unsubsribes from MQTT topic on Server
Checks if the Board is connected to a newtork and reconects if not Check if the client is connected to the server
| topic | - the topic to unsubscribe from (const char[]) |
|
private |
functionpointer to callback-function
|
private |
instance of WiFiClient
|
private |


Date: Thu, 18 Dec 1997 18:27:29 GMT Server: Stronghold/1.3.4 Ben-SSL/1.3 Apache/1.1.3 Content-type: text/html Content-length: 52436 Last-modified: Wed, 17 Dec 1997 15:24:12 GMT
Advance Paradigm is a leading independent provider of PBM services to health benefit plan sponsors, with approximately ten million health plan members enrolled in the Company's programs. The Company's primary focus is on the delivery of cost-effective, high quality, integrated PBM services.In addition, the Company has developed Health Benefit Management services and is expanding its clinical expertise and disease management services to meet the specialized needs of its plans' members, particularly those requiring costly, long-term and recurring therapies. These services are designed to inform and educate health benefit plan sponsors, their members and participating physicians of nationally recognized practice guidelines for various disease states. This encourages physician and member compliance which in turn, improves member health while reducing cost of care.
Latest Advance Paradigm press releases:
IRVING, Texas, Nov. 3 -- Advance Paradigm, Inc., (Nasdaq:ADVP), today announced that it has been selected to provide pharmacy benefit management services for Costco Companies, Inc. based in Issaquah, Washington. Under the agreement, Advance Paradigm will provide Costco with fully integrated pharmacy services including: claims adjudication, formulary management, clinical services and network management. In addition, Costco will have access to Advance Paradigm's health benefit management products including disease management and personal care management. This agreement became effective November 1, 1997, and will cover approximately 100,000 members based in 23 states.
``Our integrated clinical strategies will provide Costco with the ability to control drug cost, the flexibility to offer innovative new products and the opportunity to deliver the highest levels of service and care to their members,'' said David D. Halbert, Chairman and Chief Executive Officer of Advance Paradigm. ``Our clinical leadership, innovative information management capabilities and aggressive commitment to customer service, positions us well to meet Costco's need to provide coordinated medical care management. A good example is Advance Paradigm's decision support system, ApotheQuery(R), which is used to accurately profile physician prescribing patterns, improve compliance, and thereby positively impact the overall quality of care.''
In addition to physician and member profiling, Advance Paradigm will provide Costco Companies, Inc. with access to other AdvanceSolutions (SM) clinical intervention strategies including: AdvanceChoice (SM), an innovative Formulary POS (point of service) MAC program and AdvanceSecure (SM), a clinically focused prior authorization program.
Advance Paradigm, Inc., is a leading independent provider of health benefit management (HBM) services. The Company provides cost-effective, high quality, integrated PBM services including innovative clinical programs, mail service and sophisticated claims adjudication with PPO and EPO network management. The Company's expanding HBM programs include customized disease management programs targeted at specific disease states and personal care management (PCM) capabilities. Advance Paradigm's client base of more than 12 million lives includes HMOs, PPOs, BlueCross & BlueShield organizations, Fortune 500 employers, insurance carriers and third party administrators.
This press release includes statements which may constitute forward- looking statements under the safe harbor provision of the Private Securities Litigation Reform Act of 1995. This information may involve risks and uncertainties that could cause actual results to differ materially from the forward-looking statements. Factors which could cause or contribute to such differences include, but are not limited to, factors detailed in the Company's Securities and Exchange Commission filings.
IRVING, Texas, Nov. 3 -- Advance Paradigm, Inc., (Nasdaq:ADVP), announced today that it has been selected to provide pharmacy benefit management services on a multi-year basis to Nabisco, Inc. Under the agreement, Advance Paradigm will provide approximately 28,000 Nabisco employees with fully integrated pharmacy services including retail and mail order prescriptions, formulary management, clinical services and pharmacy network management. In addition, Advance Paradigm will provide services to enable Nabisco to implement disease management programs for chronic conditions such as diabetes. The proposed agreement will become effective January 1, 1998.``The opportunity to work with Nabisco is very exciting for us,'' said David D. Halbert, Chairman and Chief Executive Officer of Advance Paradigm. ``Advance Paradigm's pharmacy and health benefit management programs are designed to deliver high quality services in a cost-effective manner in order to help companies manage their pharmacy and medical costs.''
``Our selection of Advance Paradigm was driven by several key factors including their customer service, their experience with plan designs, and their assertive cost management program,'' said Paula Bills, Senior Director, Benefits/Employer Services for Nabisco. ``Advance Paradigm also offers a program that enables us to evaluate prescribing patterns and implement disease management programs.''
Nabisco (NYSE:NA) is a major international manufacturer of snacks and other food products, including such well-known brands in the U.S. as Oreo, SnackWell's, and Chips Ahoy! cookies; Ritz crackers; A-1 steak sauce; Grey Poupon mustards; Life Savers confections; Planters nuts and snacks; and Fleischmann's and Parkay margarine. International products include Christie, Peek Freans, Terrabusi, Yemina cookies and crackers; Royal dessert mixes; Fleischmann's yeast; and several Nabisco global brands -- Oreo, Ritz and Chips Ahoy! Nabisco markets products in the United States, Canada, and 85 other countries around the world. Last year's worldwide sales were $8.9 billion.
Advance Paradigm, Inc., is a leading independent provider of health benefit management (HBM) services. The Company provides cost-effective, high quality, integrated PBM services including innovative clinical programs, mail service and sophisticated claims adjudication with PPO and EPO network management. The Company's expanding HBM programs include customized disease management programs targeted at specific disease states and personal care management (PCM) capabilities. Advance Paradigm's client base of more than 12 million lives includes HMOs, PPOs, BlueCross & BlueShield organizations, Fortune 500 employers, insurance carriers and third party administrators.
This press release includes statements which may constitute forward- looking statements under the safe harbor provision of the Private Securities Litigation Reform Act of 1995. This information may involve risks and uncertainties that could cause actual results to differ materially from the forward-looking statements. Factors which could cause or contribute to such differences include, but are not limited to, factors detailed in the Company's Securities and Exchange Commission filings.
IRVING, Texas, Nov. 3 -- Advance Paradigm, Inc., (Nasdaq:ADVP), a leading independent provider of health benefit management (HBM) services today reported operating results for its fiscal 1998 second quarter and six months ended September 30, 1997. For the second quarter, the Company generated revenues of $114.4 million and net income of $1.7 million versus last year's $58.0 million and net income of $507,000 for increases of 97 percent and 245 percent respectively. Earnings per share were $0.17 on a 43 percent increase in shares outstanding compared to $0.07 per share for the second quarter of 1997. For the six months ended September 30, 1997, the Company reported revenues of $192.1 million an increase of 78 percent over the same period last year and net income of $3.1 million versus $1.2 million, an increase of 158 percent over the same period a year ago.David D. Halbert, Chairman and CEO, stated, ``We are proud to report another record breaking quarter for revenues, net income and claims processed. For the quarter ended September 30, 1997, the Company processed over 9.1 million pharmacy claims, an increase of 63 percent over the prior year's quarter. Beginning July 1, 1997 the Company began providing services for the United Mine Workers of America Health and Retirement Funds. The addition of this important relationship was a key contributor to the growth we experienced this quarter.''
The Company earlier today announced they have been selected to provide health benefit management (HBM) services for Nabisco and Costco Companies, Inc., including pharmacy benefit and disease management programs. Other recent new client announcements include Pharmaceutical Care Network and Wellmark, Inc. These clients represent over 2 million new lives, and bring the Company's total managed care lives to over 12 million.
``Nabisco and Costco Companies, Inc. are a direct result of the employer group initiative we implemented earlier this year,'' Halbert continued. ``Our strategy to provide services which go far beyond traditional pharmacy benefit management services has contributed to the Company's success in this and other market segments. This strategy provides integrated disease, information, personal care, and pharmacy benefit management services which focus on delivering cost effective programs which optimize outcomes and service for our clients' members.''
Advance Paradigm, Inc., is a leading independent provider of health benefit management (HBM) services. The Company provides cost-effective, high quality integrated pharmacy benefit management(PBM) services including innovative clinical programs, mail service and sophisticated claims adjudication with PPO and EPO network management. The Company continues to expand its HBM capabilities including customized disease management programs targeted at specific disease states and personal care management (PCM) capabilities. Advance Paradigm, Inc.'s client base of more than 12 million lives includes HMOs, PPOs, BlueCross and BlueShield organizations, Fortune 500 employers, insurance carriers and third party administrators.
The statements included in this press release concerning predictions of economic performance and management's plans and objectives constitute forward looking statements under the safe harbor provision of the Private Securities Litigation Reform Act of 1995. These statements involve risks and uncertainties that could cause actual results to differ materially from the forward looking statements Factors which would cause or contribute to such differences include but are not limited to factors detailed in the Company's Securities and Exchange Commission filings.
ADVANCE PARADIGM, INC.
Condensed Statement of Operations
($ in thousands, except per share data)Three Months Ended Six Months Ended
September 30, September 30,1997 1996 1997 1996
Revenues $ 114,430 $ 58,019 $ 192,140 $ 107,829
Cost of revenues 109,923 55,540 183,987 102,994
Selling, general
and administrative 2,415 1,781 4,527 3,495
Operating income 2,092 698 3,626 1,340
Interest income 726 300 1,398 505
Interest expense 0 180 0 358
Income before taxes 2,818 818 5,024 1,487
Federal income tax
provision 1,071 311 1,909 311
Net income $ 1,747 $ 507 $ 3,115 $ 1,176Net income per share $ 0.17 $ 0.07 $ 0.30 $ 0.17
Weighted average
shares outstanding 10,429,785 7,311,298 10,269,951 6,755,743
ADVANCE PARADIGM, INC.
Balance Sheet Data
(dollars in thousands)September 30, 1997 March 31, 1997
Cash $ 54,562 $ 51,086
Other current assets 52,496 37,628
Non-current assets 21,375 18,759
Total Assets $128,433 $107,473
Current liabilities $ 81,898 $ 63,850
Non-current liabilities 966 1,095
Total Liabilities 82,864 64,945Stockholders' Equity 45,569 42,528
Total liabilities and
stockholders' equity $128,433 $107,473
IRVING, Texas, Oct. 20 -- Advance Paradigm, Inc., (Nasdaq:ADVP), today announced they have been selected by Wellmark, Inc., to provide pharmacy benefit management services for approximately 1.2 million member lives covered by Wellmark, Inc. Under the agreement, Advance Paradigm will provide fully integrated pharmacy services including claims adjudication, mail service, formulary management, clinical services and network management as well as the Company's on-line comprehensive major medical program, AdvanceDirect (SM). In addition, Wellmark will utilize Advance Paradigm's health benefit management services to implement several disease management programs including diabetes, asthma and congestive heart failure. The five year agreement will become effective January 1, 1998.Wellmark, Inc. conducts business in Iowa as Wellmark BlueCross and BlueShield of Iowa, and it's subsidiary, Wellmark of South Dakota, Inc., conducts business in South Dakota as Wellmark BlueCross and BlueShield of South Dakota. They are the dominant suppliers of health coverage in those respective states. In addition, Wellmark Community Insurance, Inc. currently operates in Illinois, Wisconsin and Nebraska.
``We are very pleased to announce this pharmacy and health benefit management agreement with Wellmark,'' said David D. Halbert, Chairman and Chief Executive Officer of Advance Paradigm. ``Our strategies of delivering innovative, cost-effective programs and uncompromised customer service are consistent with the philosophy at Wellmark.''
``The decision to select Advance Paradigm was based on its ability to deliver results through an integrated health benefit management strategy,'' said Linda Sufficool, Vice President, Pharmacy-Customer Service, Wellmark, Inc. ``Advance Paradigm's disease management programs will assist us in delivering positive outcomes for our members.''
Mr. Halbert continued, ``The first step in the disease management process is identifying those members most at risk for adverse medical outcomes. Once identified, these members will be given individual attention to improve the quality of medical care.''
Advance Paradigm, Inc., is a leading independent provider of health benefit management (HBM) services. The Company provides cost-effective, high quality, integrated PBM services including innovative clinical programs, mail service and sophisticated claims adjudication with PPO and EPO network management. The Company's expanding HBM programs include customized disease management programs targeted at specific disease states and personal care management (PCM) capabilities. Advance Paradigm's client base of more than 12 million lives includes HMOs, PPOs, BlueCross & BlueShield organizations, Fortune 500 employers, insurance carriers and third party administrators.
This press release includes statements which may constitute forward- looking statements under the safe harbor provision of the Private Securities Litigation Reform Act of 1995. This information may involve risks and uncertainties that could cause actual results to differ materially from the forward-looking statements. Factors which could cause or contribute to such differences include, but are not limited to, factors detailed in the Company's Securities and Exchange Commission filings.
IRVING, Texas, Oct. 14 -- Advance Paradigm, Inc., (Nasdaq:ADVP), today announced the signing of a multi-year agreement to provide services for Pharmaceutical Care Network (PCN), a pharmacy benefit management company based in Sacramento, California. Under the agreement, Advance Paradigm will provide PCN with formulary and rebate management services to the majority of those 1.2 million members covered under Pharmaceutical Care Network's pharmacy benefit management programs. The two year agreement became effective October 1, 1997.``We are very pleased to announce this pharmacy benefit management agreement with Pharmaceutical Care Network, Inc.,'' said David D. Halbert, Chairman and Chief Executive Officer of Advance Paradigm. ``The signing of this agreement rekindles a relationship our companies shared previously, and we are looking forward to assisting PCN as they compete in the national health care marketplace.''
John T. Skhal, Pharm.D., President of Pharmaceutical Care Network stated, ``Advance Paradigm's formulary management strategies focus on delivering clinically appropriate products at the lowest possible net cost. Their strategies are very consistent with PCN's, all of which focus on delivering maximum value and quality of care.''
PCN was established in 1984 as an information and services company focused on providing clients with managed pharmacy benefit services that enable them to better control the costs associated with prescription drug benefits while improving the quality of patient care. PCN is one of the leading providers of pharmacy benefit management services, including pharmaceutical care and disease management through a national pharmacy network.
Advance Paradigm, Inc., is a leading independent provider of health benefit management (HBM) services. The Company provides cost-effective, high quality, integrated PBM services including innovative clinical programs, mail service and sophisticated claims adjudication with PPO and EPO network management. The Company's expanding HBM programs include customized disease management programs targeted at specific disease states and personal care management (PCM) capabilities. Advance Paradigm's client base of more than 11 million lives includes HMOs, PPOs, BlueCross and BlueShield organizations, Fortune 500 employers, insurance carriers and third party administrators.
This press release includes statements which may constitute forward- looking statements under the safe harbor provision of the Private Securities Litigation Reform Act of 1995. This information may involve risks and uncertainties that could cause actual results to differ materially from the forward-looking statements. Factors which could cause or contribute to such differences include, but are not limited to, factors detailed in the Company's Securities and Exchange Commission filings.
IRVING, Texas, Aug. 4 -- Advance Paradigm, Inc., (Nasdaq:ADVP), today announced it has entered into a letter of intent to renew a multi-year agreement to provide pharmacy benefit management services for Finger Lakes BlueCross and BlueShield, based in Rochester, NY. Under the agreement, Advance Paradigm will continue to provide Finger Lakes BlueCross and BlueShield with clinical consultative services including formulary management and clinical intervention strategies. In addition, the Company will provide new services including mail service and network management support. Finger Lakes BlueCross and BlueShield will also have access to Advance Paradigm's health benefit management products including disease management. The three year agreement will become effective January 1, 1998, and covers approximately 800,000 members.``Finger Lakes BlueCross and BlueShield is a very unique client, being one of the few community rated programs in the country'' said David Halbert, Chief Executive Officer of Advance Paradigm. ``Finger Lakes BlueCross and BlueShield has been one of the true innovators in managed care, and we are quite pleased to renew our long-standing relationship.''
Under its existing contract, the Company will continue to provide clinical services and will begin to provide the new services on the effective date. Advance Paradigm's integrated program is designed to help facilitate execution of the managed care strategy being employed in the Rochester, NY marketplace. Products such as AdvanceSelect(SM) which promotes therapeutic substitution of less expensive products, will provide Finger Lakes BlueCross and BlueShield with an effective tool in managing plan costs and driving appropriate drug therapy.
Advance Paradigm, Inc., is a leading independent provider of health benefit management (HBM) services. The Company provides cost-effective, high quality, integrated PBM services including innovative clinical programs, mail service and sophisticated claims adjudication with PPO and EPO network management. The Company's expanding HBM programs include customized disease management programs targeted at specific disease states and personal care management (PCM) capabilities. Advance Paradigm's client base of more than 10 million lives includes HMOs, PPOs, Blue Cross and Blue Shield organizations, Fortune 500 employers, insurance carriers and third party administrators.
This press release includes statements which may constitute forward- looking statements under the safe harbor provision of the Private Securities Litigation Reform Act of 1995. This information may involve risks and uncertainties that could cause actual results to differ materially from the forward-looking statements. Factors which could cause or contribute to such differences include, but are not limited to, factors detailed in the Company's Securities and Exchange Commission filings.
IRVING, Texas, Aug. 4 -- Advance Paradigm, Inc., (Nasdaq:ADVP), today announced that they have been selected by the State of Kansas to provide pharmacy benefit management services for the State of Kansas employees. Under the proposal accepted by the State, Advance Paradigm will provide the State of Kansas employees with fully integrated pharmacy services including: claims adjudication, mail service, formulary management, clinical services and network management. In addition, the State will have access to Advance Paradigm's health benefit management products including disease management and personal care management. The proposed multi-year agreement will become effective December 28, 1997, and covers approximately 90,000 members.``We are very pleased to have been chosen to administer the State of Kansas' prescription program,'' said David D. Halbert, Chief Executive Officer of Advance Paradigm. ``Our experience with other state programs, coupled with our focus on integrated clinical strategies will provide the State of Kansas with the tools to successfully control drug costs, while at the same time provide their members quality benefits and the highest levels of customer service.'' ``In order to maximize the pharmacy benefit,'' Halbert continued, ``Advance Paradigm will be providing the State of Kansas with access to several proprietary clinical intervention strategies including: AdvanceChoice(SM), an innovative Formulary POS (point of service) MAC program; AdvanceSecure(SM), a clinically focused prior authorization program, and AdvanceSelect(SM), which promotes therapeutic substitution of less expensive products. Each of these programs facilitate clinically appropriate therapy at the lowest overall cost.''
Advance Paradigm, Inc., is a leading independent provider of health benefit management (HBM) services. The Company provides cost-effective, high quality, integrated PBM services including innovative clinical programs, mail service and sophisticated claims adjudication with PPO and EPO network management. The Company's expanding HBM programs include customized disease management programs targeted at specific disease states and personal care management (PCM) capabilities. Advance Paradigm's client base of more than 10 million lives includes HMOs, PPOs, Blue Cross and Blue Shield organizations, Fortune 500 employers, insurance carriers and third party administrators.
This press release includes statements which may constitute forward- looking statements under the safe harbor provision of the Private Securities Litigation Reform Act of 1995. This information may involve risks and uncertainties that could cause actual results to differ materially from the forward-looking statements. Factors which could cause or contribute to such differences include, but are not limited to, factors detailed in the Company's Securities and Exchange Commission filings.
IRVING, Texas, August 4 -- Advance Paradigm, Inc., (Nasdaq:ADVP), a leading independent provider of health benefit management (HBM) services today reported operating results for its fiscal 1998 first quarter ended June 30, 1997. For the first quarter, the Company generated revenues of $77.7 million and fully taxed net income of $1.4 million versus last year's $49.8 million and $669,000 for increases of 56 percent and 105 percent respectively. Earnings were $0.14 per share on a 63 percent increase in shares outstanding compared to $0.11 per share for the first quarter of 1997. No tax provision was recorded in the quarter ended June 30, 1996, as the result of available net operating loss carry forwards. On a fully taxed basis, earnings for the quarter ended June 30, 1996 would have been $0.07 per share.David D. Halbert, Chairman and CEO, stated, ``The Company continues to experience strong growth in new clients and from an increase in member lives from existing clients. We are proud to report another record breaking quarter for revenues and net income. For the quarter ended June 30, 1997, the Company processed over 8.1 million pharmacy claims, an increase of 59 percent over the prior year's quarter.''
The Company also announced today that the State of Kansas has selected Advance Paradigm to provide pharmacy benefit management services to their approximately 90,000 members effective December 28, 1997. In addition, the Company announced it has entered into a letter of intent to renew their multi- year pharmacy benefit management services agreement with Finger Lakes BlueCross and BlueShield effective January 1, 1998. The agreement provides services to approximately 800,000 members.
Advance Paradigm, Inc., is a leading independent provider of health benefit management (HBM) services. The Company provides cost-effective, high quality integrated pharmacy benefit management(PBM) services including innovative clinical programs, mail service and sophisticated claims adjudication with PPO and EPO network management. The Company continues to expand its HBM capabilities including customized disease management programs targeted at specific disease states and personal care management (PCM) capabilities. Advance Paradigm, Inc.'s client base of more than 10 million lives includes HMOs, PPOs, Blue Cross and Blue Shield organizations, Fortune 500 employers, insurance carriers and third party administrators.
The statements included in this press release concerning predictions of economic performance and management's plans and objectives constitute forward looking statements under the safe harbor provision of the Private Securities Litigation Reform Act of 1995. These statements involve risks and uncertainties that could cause actual results to differ materially from the forward looking statements Factors which would cause or contribute to such differences include but are not limited to factors detailed in the Company's Securities and Exchange Commission filings.
ADVANCE PARADIGM, INC.
Condensed Statement of Operations
($ in thousands, except per share data)
Three Months Ended June 30
1997 1996
Revenues $77,710 $49,809
Cost of revenues 74,064 47,454
Selling, general and administrative 2,112 1,714
Operating income 1,534 641
Interest income 672 205
Interest expense 0 177
Income before taxes 2,206 669
Federal income tax provision 838 0
Net income $1,368 $669
Net income per share $0.14 $0.11
Weighted average shares
outstanding 10,110,116 6,200,187
ADVANCE PARADIGM, INC.
Balance Sheet Data
(dollars in thousands)
June 30, 1997 March 31, 1997
Cash $51,696 $51,086
Other current assets 37,767 37,628
Non-current assets 19,845 18,759
Total assets $109,308 $107,473
Current liabilities $64,271 $63,850
Non-current liabilities 1,184 1,095
Total liabilities 65,455 64,945
Stockholders' equity 43,853 42,528
Total liabilities and
stockholders' equity $109,308 $107,473
Irving, Texas, May 21 -- Advance Paradigm, Inc., (Nasdaq:ADVP), today announced a letter of intent providing for a multi-year agreement to provide pharmacy benefit management services for the United Mine Workers of America Health and Retirement Funds ("Funds"). Under the proposed agreement, Advance Paradigm will provide pharmacy benefit management services, several disease management programs and assistance with the Funds' medical management initiatives."The opportunity to work with the Funds is very exciting for us," said David D. Halbert, Chief Executive Officer of Advance Paradigm. "The Funds present a unique set of health care management challenges which our health benefit management initiatives have been designed to address. Through a collaborative effort with the Funds' staff, we will work to positively impact not only the Funds' beneficiaries' quality of care, but also help control the Funds' overall health care costs."
"The demographics for the Funds' beneficiaries are quite different from what we typically see," Halbert continued. "With an average age of nearly 78, this population faces the many challenges of advancing age and its associated illnesses. Advance Paradigm's initial disease management focus will be on Diabetes, Hypertension and Congestive Heart Failure which all have significant impact on this geriatric population."
The UMWA Health and Retirement Funds is a group of six multi-employer benefit plans that provide benefits to eligible coal industry retirees and their families. The three health benefit plans consist of the Combined Benefit Fund, the 1992 Benefit Plan and the 1993 Benefit Plan and covers approximately 90,000 beneficiaries located primarily in rural areas. These plans provide over $100 million per year in pharmacy benefits.
Advance Paradigm, Inc., founded in 1986 and based in Irving, Texas, is a leading independent provider of health benefit management (HBM) services. The Company provides cost-effective, high quality, integrated PBM services including innovative clinical programs, mail service and sophisticated claims adjudication with PPO and EPO network management. The Company's expanding HBM programs include customized disease management programs targeted at specific disease states and personal care management (PCM) capabilities. Advance Paradigm's client base of approximately 10 million lives includes HMOs, PPOs, Blue Cross and Blue Shield organizations, Fortune 500 employers, insurance carriers and third party administrators.
This press release includes statements which may constitute forward- looking statements under the safe harbor provision of the Private Securities Litigation Reform Act of 1995. This information may involve risks and uncertainties that could cause actual results to differ materially from the forward-looking statements. Factors which could cause or contribute to such differences include, but are not limited to, factors detailed in the Company's Securities and Exchange Commission filings.


GitHub ReposApp
Search GitHub Repository
account_circle
Username
search
Find repos
search
Find repos by stars (asc)
search
Find repos by stars (desc)


Wild Things (1998)
***1/2 out of *****
Cast: Kevin Bacon, Matt Dillon, Neve Campbell, Theresa Russell, Denise Richards, Robert Wagner, Bill Murray Written by: Stephen Peters Directed by: John McNaughton Running Time: 113 minutes
I have to refrain from thinking like a typical guy as I review Wild Things. A typical guy should just go nuts for this sort of trash, easily giving it a rave review.  You've got lots of attractive women either soaking wet, in bathing suits, their underwear, or just flat out nude. You've got sex scenes, including girls making out with one another. And you've got the world famous two-girl cat fighting. But I'm not your typical guy.  Thankfully though, Wild Things delivers in other areas. Areas that real movies need to deliver in.
Wild Things is so sleazy that scum bag... I mean screenwriter Joe Eszterhas (Showgirls, Jade) must be convinced that he wrote it. You've got shades of Basic Instinct, Body Heat, and even Diabolique in there. Taking place in South Florida, Matt Dillon plays a high school guidance counselor (at a school which all the women are practically bursting out of their clothing, and there's not one remotely unattractive girl in the whole place). Early on in the film, he is charged with rape by one of his students (Denise Richards). Then another girl (Neve Campbell) also accuses Dillon of rape. What I've just described is the basis of the film, yet I haven't even scratched the surface on all the slime which will be presented to you. Nor will I even try to do so. The story takes so many twists, turns, and double-crosses that you just might get lost.
 Now the dialogue is laughably bad in most scenes, but it's usually delivered by the actors with that sort of tongue-in-cheek attitude, as of they are saying "Yes, we know it's silly too. Just watch." much like most of Starship Troopers was. The writer obviously knows this isn't Citizen Kane, doesn't he?. Bill Murray, brilliant as always, plays the strip-mall lawyer that Dillon hires to defend him. He adds the intentional humor. He has about 20 minutes of screen time, and it's all great stuff. The rest of the cast seems to be acting adequately enough, with the possible exception of Theresa Russell, who makes up for her bad acting by being scantily dressed most of the time. And Kevin Bacon (who also executive-produced) has one quick scene that will let you make as many new "Six Degrees of Kevin Bacon" jokes as you'd like. When you see it, you'll know what I mean.
A big problem I had was that the film spent way too much time trying just to confuse the audience. Forget the fact that the amount of double-crossing going on would just never work, what I'm talking about are individual scenes which are presented to the audience solely to fool us. Characters who have ulterior motives obviously have to act inconspicuous around others, yet many times they just keep acting, even when no one else is around!
Even as the closing credits start to roll, you'll want to stay in your seat as the film will flash back to earlier events, explaining itself. I don't believe I've ever seen that before, and it was a pretty interesting idea. Just be sure to stay seated, people behind you get pretty ticked off when you stand up to leave, and then keep standing to watch the screen.
Wild Things is certainly trash, no doubt about that, but it's entertaining trash. It knows it, and doesn't try to be anything but. It's humorous, both intentionally and unintentionally. And the story, while completely absurd, is interesting to watch unfold. And watching it unfold around young scantily clad women climbing out of swimming pools? Even better. [R]
The Jacksonville Film Journal -- Film Reviews by Chuck Dowling URL: http://users.southeast.net/~chuckd21/ Email<EMAIL_ADDRESS>© 1995-1998 of The Jacksonville Film Journal. No reviews may be reprinted without permission.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Interface IRecordHolder
- All Known Implementing Classes:
Table
public interface IRecordHolder
Interface for a container for one or more indexed records implementing
IRecord
.
Record holders' directly equivalent sources might include, e.g. a file of
data or a database table. The are contained in IDataset
objects
(e.g. representing directories or databases).
- Author:
- Andy Evans
- See Also:
IRecord
- Version: 1.0 01 Mar 2021
-
Method Summary
Modifier and Type Method Description void
addRecord(IRecord record)
Should add a singleIRecord
to the end of the holder.void
addRecords(ArrayList<IRecord> records)
Should add a collection ofIRecord
objects to the end of the container.ArrayList<String>
getFieldNames()
Should get the field names for thisRecordHolder
.ArrayList<Class>
getFieldTypes()
Should get the field types for thisRecordHolder
.IMetadata
getMetadata()
Should get the metadata for thisRecordHolder
.IDataset
getParentDataset()
Should return the dataset thisRecordHolder
is part of, or null if none.IRecord
getRecord(int index)
Should get a singleIRecord
at an index.ArrayList<IRecord>
getRecords()
Should get allIRecord
objects.void
setFieldNames(ArrayList<String> fieldNames)
Should set the field names for thisRecordHolder
.void
setFieldTypes(ArrayList<Class> fieldTypes)
Should set the field types for thisRecordHolder
.void
setMetadata(IMetadata metadata)
Should set the metadata for thisRecordHolder
.void
setRecord(int index, IRecord record)
Should set a singleIRecord
in the holder at index position.
-
Method Details
-
getParentDataset
IDataset getParentDataset()Should return the dataset thisRecordHolder
is part of, or null if none.- Returns:
- IDataset Parent data set or null.
-
setMetadata
Should set the metadata for thisRecordHolder
.- Parameters:
metadata
- The metadata object for thisRecordHolder
.
-
getMetadata
IMetadata getMetadata()Should get the metadata for thisRecordHolder
.- Returns:
- IMetadata The metadata object for this
RecordHolder
.
-
setFieldNames
Should set the field names for thisRecordHolder
.- Parameters:
fieldNames
- The field names for thisRecordHolder
.
-
getFieldNames
Should get the field names for thisRecordHolder
.- Returns:
- ArrayList The field names for this
RecordHolder
.
-
setFieldTypes
Should set the field types for thisRecordHolder
.- Parameters:
fieldTypes
- The field types for thisRecordHolder
.
-
getFieldTypes
Should get the field types for thisRecordHolder
.- Returns:
- ArrayList The field types for this
RecordHolder
.
-
setRecord
Should set a singleIRecord
in the holder at index position.- Parameters:
index
- Location of Record.record
- Record to add.
-
addRecord
Should add a singleIRecord
to the end of the holder.- Parameters:
record
- Record to add.
-
addRecords
Should add a collection ofIRecord
objects to the end of the container.- Parameters:
records
- Records to add.
-
getRecord
Should get a singleIRecord
at an index.- Parameters:
index
- Location of record.- Returns:
- IRecord Record requested.
-
getRecords
Should get allIRecord
objects.- Returns:
- ArrayList All records.
-


The Seattle Academy Marine Biology Club is a club based aroudn the marine environment of Seattle and the general well-being of the marine life that lives next to us. We conduct service trips and fundraisers in order to assist in the protection of our local sealife.
Pacific Cleanup Bake Sale (30 min of service redeemable)
Leschi Beach Cleanup Effort (3 hours of service redeemable)
We'll be taking a group field trip down to the Seattle Aquarium and piers


Enter a regular expression and press 'Submit'. Page will generate random strings until one matches the expression.
If the number of tries hits the limit set by the slider, then it stops trying to create a string that matches.
This uses pure brute force in generating the string.
All processing for the string generation is done in your browser, so no information is ever sent over the internet.
Once your string is gerenated, you can check it against the 'haveibeenpwned' database to see if this value
has come up in any data breaches. More information on how that works can be found
here.


A Fresh Perk App
Newly installed and ready to go!
We recommend checking out the
documentation
if you haven't already.


France
By Jack Mac Namara
France, also known as République Francaise, is the oldest and largest country in the EU and one of the most important in the world. Its exquisite cuisines, magnificent art, culture and captivating history and landscapes, make it a country that is truly spectacular.
Learn More >Iceland
By Scott Brady
Discover the volcanoes, geysers, lava fields, mountains and glaciers of Europe's second-largest island, commonly known as “The Land of Fire and Ice” and its long summer days with nearly 24 hours of sunshine, offset by shorter winter days with only a few hours of light.
Learn More >Nigeria
By Okikiola Sanni
Nigeria is a diversified country in the West of Africa. It is known to be the “Giant of Africa”. It is a home to millions of individuals, and over 250 ethnic groups, more than 500 languages and butterfly species.
Learn More >New Zealand
By Peadar McHenry
New Zealand is an island country located in the south-western Pacific Ocean. It consists of two islands. It is a country filled with rich culture which mainly comes from the ethnic group called Māori.
Learn More >Spain
By Connor Byrne
Spain is a country located in south western Europe that is home to the second most spoken language in the world, Spanish. Spain is famous for its good food, great people, its scenic beauty and its vast coastline.
Learn More >Contact Us & More Info
A group effort!
Information about the website, including who-did-what, lessons we learned along the way, and a form to contact us with any questions you may have about the website and its content or creation.
Learn More >


Who We Are
We concentrate on building long term relationships with the leading clubs, brands, associations, venues and unions worldwide.
We act as the connection between carefully selected clients and outstanding candidates.
What We Do
We concentrate on building long term relationships with the leading clubs, brands, associations, venues and unions worldwide.
We act as the connection between carefully selected clients and outstanding candidates.
Clients
We offer flexible, temporary and permanent recruitment solutions that will deliver results.
Our recruitment consultants offer in-depth industry knowledge and build strong, long term relationships with our clients.
Taking the time to source the best talent in the industry, each candidate is screened and vetted assuring only the best quality of candidates are presented to you.
Candidates
We are the premier sports recruitment agency within the industry. Our large network of clients are looking for outstanding candidates, we are here to work closely with you and guide you on your recruitment journey.
You will receive a discreet and confidential service ensuring that your next career move is dealt with professionally.
Upload your CV or contact us to find out how we can help you achieve your career aspirations and find you the perfect job.


Aim: Designing the user interface and visualization dashboard for PoPS model
Agenda
intro to design thinking
define problems
ideate session 1
break
ideate session 2
Design Thinking
Design Thinking is a design methodology
that provides a solution-based approach to solving problems. It’s
extremely useful in tackling complex problems that are ill-defined or unknown
, by understanding the human needs involved, by re-framing the problem
in human-centric ways, by creating many ideas in brainstorming sessions
, and by adopting a hands-on approach in prototyping and testing. .
five steps in design thinking
Empathize
Empathy is when you can feel what another person
is feeling. Empathy is the foundation of a human centered
design process; by deeply understanding
people we are better able to design for them.
Empathize
Assuming a Beginner’s Mindset
Ask What? How? Why?
Photo and Video User-based Studies
Personal Photo and Video Journals
Interviews
Engaging with Extreme Users
Bodystorming
What? How? Why?
What is the person you’re observing doing in a
particular situation? (objective)
How is he doing it? Does it require effort? Does
he appear rushed? Pained? Happy? Is the activity
impacting the user in either positive or negative way?
Why is he doing what he’s doing, in the way he’s doing
it? (informed guess)
Define
Analysis of observations and their synthesys to define the core problems that identified in empathy step.
Problem are defined in a form of problem statements in a human-centred manner.
Define problem
Human-centred
is about the people the team is trying to help
is not about technology, monetary returns or product specifications.


Back Step 8 of 16
{{ ptitle }}
The judge will decide whether your appeal can continue without paying the tax first. If the judge doesn't accept your reasons, your appeal won't go ahead and your fee won't be refunded.
Back Step 8 of 16
The judge will decide whether your appeal can continue without paying the tax first. If the judge doesn't accept your reasons, your appeal won't go ahead and your fee won't be refunded.


Getting Started with Phood Api¶
The phood api provides access to users, payment types, payment balance and other phood delivery resources.
Accessing the Phood API GraphQL endpoint¶
You can access the Phood API GraphQL endpoing using GraphiQL, curl or any HTTP client. You SHOULD use the POST method for all requests.
The GraphQL endpoint is
https://phood-api-prod.herokuapp.com/graphql
Authentication¶
The Phood API also requires an access token, which can only be obtained with a valid account.
All authorization methods will return an authorization token that shoul be passed to the header.
Authorization: Bearer <token>
Curl Example with authorization token in the header
curl \
-H "Content-Type: application/json" \
-H "Authorization: Bearer EBnKHEB.DvtHpdHTruklmS3g2Lf5tswGqTvG2t9uBBbXeotAQE4" \
-X POST https://phood-api-prod.herokuapp.com/graphql \
-d '{ "query": " query{ me {email} }" }'
Curl Example¶
This is an Example of a Curl request of the authenticate shown above.
curl \
-H "Content-Type: application/json" \
-X POST https://phood-api-prod.herokuapp.com/graphql \
-d '{ "query": " mutation Authenticate($userEmail:String!, $userPassword:String!){
authenticate(email:$userEmail, password:$userPassword) }",
"variables": { "userEmail"<EMAIL_ADDRESS>"userPassword": "password1234"} }'


Google Cloud HatSpin
Learn more
Node.js on Google Cloud
Node.js samples
About me
VOTE
View Source
Vote counted!


-
Counter
The "Hello World" of FreeDOM, counter shows how to create a basic backend module in FreeDOM
and communicate between the page and the module.
FreeDOM modules encapsulate the backend of the application and can be migrated
across devices with minimal effort.
counter.json
counter.js
page.js
README.md
-
TicTak
TicTak demonstrates a single player game making use of the FreeDOM Storage API.
TicTak uses the default Storage provider, to store game stats.
tictak.json
main.js
README.md
-
Chat
Chat demonstrates how to use the FreeDOM Social API to enable multi-user interactions.
In this basic example, the Social API is used to send chat messages, where all users
who use the app will join a global buddylist with a GUID.
chat.json
main.js
page.js
README.md
-
File Drop
File Drop demonstrates how to use the Transport API alongside the Social API
to create a powerful P2P file transfer utility.
filedrop.json
main.js
page.js
page.css
README.md


EsTools Class
ElasticSearch Tools for interfacing
Constructor
EsTools
()
Item Index
Methods
_addCompound
-
type
-
kind
Private:
Adds item to query
Parameters:
Returns:
Returns this for chaining.
_addCompound
-
type
-
kind
-
path
Private:
Adds compound query type to query
Parameters:
Returns:
Returns this for chaining.
_addObj
-
type
-
options
Private:
Adds Object to _parent path. Used only for highlight right now
Parameters:
Returns:
Returns this for chaining.
_addToQuery
-
type
-
options
Private:
Adds any passed variable to the root of the returned query
Parameters:
Returns:
Returns this for chaining.
from
-
from
Public:
Adds from to query
Parameters:
-
from
IntegerStart of offset for query
Returns:
Returns this for chaining.
getMapping
()
Object
private
Gets the mapping from ElasticSearch in form of array.
Returns:
Object containing arrays of mappings. e.g. {'post':[{mapping:'body', type:'string'}]}
getQuery
()
Object
Public:
Gets full query ready to send to elasticsearch
Returns:
Returns query object.
page
-
page
-
size
Private:
Convert page to offset for use with pagination
Parameters:
-
page
IntegerPage that request is on.
-
size
IntegerSize of pages (optional).
Returns:
Returns offset.


GEOIPLOOKUP6(1) GEOIPLOOKUP6(1) NAME geouplookup6 - look up country using IP Address or hostname SYNOPSIS geouplookup6 [-d directory] [-f filename] [-v] <ipaddress|hostname> DESCRIPTION geouplookup6 uses the GeoIP library and database to find the Country that an IP address or hostname originates from. You must install a database suitable for geoiplookup6. IE: GeoIPv6.dat For example: geouplookup6 2001:4860:0:1001::68 geoiplookup6 ipv6.google.com will find the Country that 2001:4860:0:1001::68 originates from, in the following format: US, United States OPTIONS -f Specify a custom path to a single GeoIP datafile. -d Specify a custom directory containing GeoIP datafile(s). By default geouplookup6 looks in /usr/share/GeoIP -v Lists the date and build number for the GeoIP datafile(s). AUTHOR Written by T.J. Mather REPORTING BUGS Report bugs to<EMAIL_ADDRESS>COPYRIGHT Copyright Â© 2008 MaxMind LLC This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. SEE ALSO geoipupdate(1), nslookup(1). 4th Berkeley Distribution 28 Oct 2008 GEOIPLOOKUP6(1)