Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document provides an overview of the role of delivery context in achieving a device independent Web. It describes the kind of information that may be included in the delivery context, and how it may be used. It surveys current techniques for conveying delivery context information, and identifies further developments that would enhance the ability to adapt content for different access mechanisms.
This document is one of a series produced by the W3C Device Independence Working Group. Other documents in the series address the implementation of solutions to the requirements raised here. For example, there are documents in the series reviewing current techniques that can be used to address these requirements and exploring how future versions of existing W3C specifications can provide solutions.
Details of the entire series of documents can be found on the W3C Device Independence Activity home page.
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/.
This document is a W3C Working Group Note. It represents the views of the W3C Device Independence Working Group at the time of publication. The document may be updated as new technologies related to the delivery maxf context emerge or mature. 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 is one of a series produced by the Device Independence Working Group(Member Only Link), part of the W3C Device Independence Activity. The DIWG activity statement can be seen at http://www.w3.org/2001/di/Activity.
Comments on this document can be sent to<EMAIL_ADDRESS>the public forum for discussion of the W3C's work on Device Independence. To subscribe, send an email to<EMAIL_ADDRESS>with the word subscribe in the subject line (include the word unsubscribe if you want to unsubscribe). The archive for the list is accessible online.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. 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.
The earlier Device Independence Principles document [DIP] set out a number of principles that can lead to greater device independence in delivering Web content and applications. Terms from this document, and others related to device independence, are collected in the Glossary of Terms for Device Independence [GLOSS]. A link is provided to the Glossary definition when a term is first used in the following text.
The term delivery context, as used when discussing web delivery (first introduced in [DIP]), refers to:
A set of attributes that characterizes the capabilities of the access mechanism, the preferences of the user and other aspects of the context into which a web page is to be delivered.
In this document, the kind of information that may relate to the delivery context is described. The role of delivery context and adaptation in Web architecture is illustrated. Techniques for representing, conveying and processing delivery context are considered. Existing technologies that address these needs are reviewed. Areas that are under development by the W3C Device Independence Working Group to address remaining needs are outlined.
Delivery context includes many factors that could have some effect on the resultant experience of the delivered content by the user. Section 1.1 gives some illustrations of possible characteristics of the delivery context. Section 1.2 focuses on those characteristics that are particularly relevant to device independence.
There are many aspects of the delivery context that may influence which representation of some Web content is best delivered in response to a request. In this section, we hint at the range of potential characteristics that might be expressed in the delivery context. However, the set of potential characteristics is open-ended, so this list is only illustrative.
It is worth noting here that some of these characteristics could be considered as conveying sensitive information. Issues associated with privacy and trust are considered outside the scope of this particular note. Some of the challenges are discussed in 6.3 Trust and Privacy.
Some of the above characteristics may be intrinsic to, or can be evaluated by, the delivery device; others may be set, or overridden, by the user. Some characteristics may stay fixed for long periods (such as the communications protocols supported by the device); others may vary from one moment to the next (such as geographic coordinates, or temperature). Any particular device will only support a subset of all possible characteristics, though that subset may change over time.
Because of such variability, it is unlikely that any complete definition of a well-defined set of delivery context characteristics can exist. However, to allow for the evolution of a set of characteristics that can be of practical use in delivering appropriate content across a wide range of contexts, it is important that definitions of well-defined characteristics for subsets of the context can be re-used.
Diagram 1.1: Scope of delivery context characteristics
In some situations, there may be delivery context characteristics that are specific to a particular application. However, many characteristics may be useful to many applications. If each application were to define a different representation for its delivery context characteristics, it would require each delivery device to maintain delivery context information on a per-application level. Applications would need to know about devices, and devices would need to know about applications. This goes against the 'network effect' that the Web encourages, whereby Web content and applications, and the delivery devices use to access them, can be developed independently but in a mutually reinforcing manner.
For the remainder of this Note, we will focus on the issues that must be addressed when defining and sharing delivery context information in an application-independent way. This is particularly the case when trying to provide general solutions to achieve device independence.
Within the set of well-defined, application-independent delivery context characteristics, an important subset are those that may help deliver web content more effectively across a wide range of delivery devices.
Diagram 1.2: Scope of delivery context characteristics relevant to device
independence
The characteristics that are most relevant for achieving device independence are those that characterize the capabilities of the access mechanism, the capabilities of the network and some of the preferences of the user. In particular, a user may specify adaptation preferences and rendering preferences that affect the user experience they have of the delivered content (see [DIP] for further details).
For device independence, delivery context information is typically used to provide an appropriate format, styling or other aspect of some web content that will make it suitable for the capabilities of a delivery device. The adaptation required to achieve this may be performed by an origin server, by an intermediary in the delivery path, or by a user agent.
From the point of view of device independence, the main concern is accurately reflecting the capabilities of the access mechanism and the preferences of the user. Given appropriate information about the delivery context, the delivered content can be adapted to provide a functional user experience on that device, or may be further adapted to provide a harmonized user experience (as defined in [DIP]). The possible adaptations that could be performed on the available content can only be determined once the delivery context information is known.
The W3C Device Independence Group is defining a set of specifications related to the use of delivery context for delivering and running adapted content accross a wide range of devices. One activity is the Delivery Context Interfaces work that aims to provide a platform independent API for accessing delivery context information that can be used during both server-side and client-side content adaptation. This goal is described in more details in section 5.5.
In this section, motivation for more effective use of delivery context information is provided from the perspectives of users, authors and implementers.
From the perspective of the user, the technology for conveying delivery context information is largely invisible. For example, a user is not usually aware of the values inserted into an HTTP request header. But the user may need a mechanism to set preferred delivery context characteristics when necessary.
Some aspects of the delivery context, such as the underlying capabilities of the access mechanism, can be set automatically by software through internal configuration parameters. An example of such a characteristic might be the screen size of a visual rendering device.
Other aspects of the delivery context, such as user preferences, will normally require user configuration. User preferences related to user experience choices, may be managed by the user agent responsible for rendering some Web content. User preferences related to application personalization could also be transmitted as part of the delivery context, but are outside the scope of this document since they are inherently application-dependent.
Because the kind of content that is delivered may depend on the characteristics that are conveyed in the delivery context, it is important that the user is provided, through appropriate software and interaction, with sufficient flexibility to control those characteristics. This is particularly important where the needs of the user may differ from those provided in standard configurations.
Currently it is not clear how privacy of delivery context information is best addressed. The user may not wish certain pieces of information contained in the delivery context to be made available to untrusted components along the delivery path. For example, the user may wish information about their location to be made available to a trusted application, but not to any intermediate node through which the delivery context information may pass. This and other characteristics in the delivery context, individually or collectively, may indirectly constitute personally identifiable information, and so are subject to the security and privacy concerns considered in more detail in Section 6.3.
From the perspective of the application developer or content author, it is important to be able to access delivery context information in order to deliver the most appropriate kind of content.
In some situations, the application developer may rely on some underlying adaptation process to select and format the appropriate content version. For example, commercial image servers are available that can scale and convert the format of images to suit the rendering capabilities of different devices.
In other situations, the content author may indicate within their content that different selections should be made according to the client capabilities. For example, markup to express context-dependent styling has been included in CSS Media Queries [MQ]. Proposals to allow context-dependent content selection are under development [DI-sel].
In yet other situations, the application developer may explicitly create transformations which can adapt their content for different devices. For example, stylesheets written in XSLT may be applied to content expressed in XML to produce different deliverable presentation markup.
In order to make effective use of the delivery context information, the application developer needs the characteristics to be both well-defined and common across as many devices as possible. This raises issues of the definition and re-use of vocabulary elements, as discussed in Section 5.4.
Delivery context support may need to be implemented in system components such as user agents, web servers and proxy servers. From the point of view of a delivery context system implementer, several components need to be defined to ensure interoperable implementations:
Specific implementations might further define ways in which delivery context information might be accessed via application program interfaces or cached in data repositories.
Delivery context information may capture diverse aspects of an access mechanism, may be augmented or processed by different kinds of intermediaries, and may be used by different application components in an origin server or intermediary. This means delivery context has to be supported by many software components along the delivery path. It will not necessarily be the case that a single software component creates the whole delivery context, and another single component accepts it and adapts content accordingly.
From the perspective of the implementer, software components must be able to create a delivery context, augment an existing delivery context with their own characteristics, replace parts of a delivery context to reflect the possible adaptation capabilities of the component, and decompose a delivery context to extract the characteristics which will control their processing.
To date, the user agent, usually based on the client, has been the software component that has been responsible for constructing a request for some Web content, and has therefore also assumed responsibility for creating any client-related delivery context. However, with access mechanisms that may increasingly include several hardware or software components, a more flexible way of building the delivery context will be required.
For example, a mobile device may be temporarily within range of a local LAN which provides fast Internet access as well as connection to a nearby printer and a large screen. By interacting with their mobile device, the user may wish to deliver some Web content on the printer or the screen. The delivery context may include characteristics, or references to characteristics, contributed by several components. Hardware characteristics may be provided by the printer, the screen and the mobile device. Software characteristics may be provided by the mobile device's operating system, user agent, and local media handling capabilities. Network characteristics may be provided relating to the LAN connection. User preferences may be provided relating to the user experience of the content to be accessed.
As the range of characteristics made available through the delivery context grows, so the implementer of the content adaptation process requires better mechanisms to extract the relevant characteristics from the delivery context.
For example, if multiple overlapping characteristics exist within the delivery context, such as the pixel dimensions of the presentation spaces of each of the mobile device, the printer and the screen in the previous example, resolution rules or other mechanisms are required to determine which characteristics should be used.
The overall Architecture of the World Wide Web [WEB-arch] describes how information resources can be accessed and how multiple representations of the resource may be retrieved. This section looks at the role of delivery context within this overall architecture.
The role of the delivery context in accessing web-based content and applications is illustrated in the following diagrams.
Diagram 3.1: Client provides delivery context as well as request
The client which originates a request for some web content may also include some delivery context information which can help that request to be handled appropriately. In practice, the context information may be included as part of the request, or some (or all) of it may be supplied indirectly as a reference to information that is stored separately.
Delivery context information may also be used locally. For example, the amount of ambient light may be part of the delivery context information that is used to alter the brightness of a display. However, this use of delivery context is independent of the Web architecture.
Diagram 3.2: Server uses delivery context to adapt response
The server which responds to some request for web content may use delivery context information to adapt its response to better suit the needs of the client. Such server-side adaptation may include providing an appropriate data (MIME) type for the response, or an appropriate natural language in which to express text content, or even selecting appropriate application-specific data suited to the locale of the client.
Diagram 3.3: Intermediary may augment delivery context and adapt response
An intermediary in the path between client and server may also provide adaptation. The intermediary may modify the request, including providing new delivery context information, in such a way that the response can be adapted appropriately. For example, a transcoding proxy may offer to accept a media type not included in the original request. When the response is received by the proxy, that media type is adapted to one that is acceptable to the originator of the request.
In the most general situation, a sequence of intermediaries may provide additional delivery context information at different points in the request path from client to server and may modify the response in the response path between the server and the client. The response may be modified based on any delivery context information available at that point in the response path.
In some situations, an intermediary may block delivery context information from being passed further along the request path. For example, a phone may pass information about its location only as far as a mobile gateway, which does not make it available to the origin server.
The delivery context also has wider significance than its usage in developing adapted content. The application that runs on the user agent (typically the client device) can utilize the device and environment context information for providing contextual adaptation. One mechanism for accessing the system and environment context is the Delivery Context Interfaces (DCI) developed by the DI working group. Here, through the use of application scripts, a decision can be made as to whether adaptation can continue on the client side or new content is needed from server based on the current context.
Various approaches to defining delivery context, or at least some aspects of it, already exist. Indeed, the need to negotiate which version of a document should be delivered to a user was recognized in the early days of the Web [HTTPneg].
In this section, the main approaches that are already in use on the Web are reviewed.
The Hypertext Transport Protocol HTTP [HTTP] is the basis for most current Web-based information delivery. It defines a number of standard accept headers that can be used to match the capabilities of a requesting device (or, in particular, its user agent) to the information that is delivered from an origin server. Standard HTTP 1.1 accept headers include:
In addition to the accept headers, the User-Agent header usually contains a string giving information about the user agent. Typically this includes the name of the manufacturer, the version number and a name. For mobile devices, it often includes information about the device hardware and the browser being used. There are no standards about how user agent information is constructed. Nevertheless, sophisticated algorithms may use it to try to identify the device and browser software being used. A number of existing systems use this identification to access a repository of information about the capabilities of the device and browser. Adaptation of content for user experience can then be made based on knowledge of these capabilities.
While HTTP headers are currently the most widely used delivery context information, they are difficult to extend, and have (particularly in the case of the User-Agent header) free-form values that are difficult to interpret.
It is possible for a server to select content based simply on the HTTP header information. In HTTP 1.1 [HTTP] this is called server-driven negotiation.
In this case, the server determines which alternate to send to a user agent as a result of examining the user agent's request header fields. Currently HTTP 1.1 uses the following request-header fields, as described in the previous subsection, for server-driven negotiation: Accept, Accept-Charset, Accept-Encoding, Accept-Language. Each of these fields is referred to as a dimension of negotiation. In order to express user or browser preferences, the request-header fields may include an associated quality value for each dimension of negotiation.
For example the following header indicates that French resources are preferred to English resources.
Accept-Language: fr; q=1.0, en; q=0.5
There are some disadvantages associated with server-driven negotiation. Firstly the information sent in the request header does not give a complete description of the capabilities of the client. For example there is no way to distinguish between images intended for handheld computers from desktop computers if they both use the same MIME type. Secondly it is inefficient for a user agent to describe its full capabilities to a server for every request it makes. Finally server-driven negotiation causes problems for caches shared by multiple devices.
It is also possible within HTTP 1.1 to support agent-driven negotiation, in which the user agent is responsible for selecting the most appropriate content. The server initially responds with a list of available representations, which then allows the user agent to make another request for the preferred representation. However, this has the disadvantage of introducing additional delay through multiple request-response round trips.
The W3C has specified a data structure and sample vocabulary for profiles which can convey delivery context information. The current Composite Capabilities/Preferences Profile (CC/PP) [CCPP-struct-vocab] is based on the original XML serialized Resource Description Framework (RDF) [RDF].
The CC/PP structure is vocabulary independent and allows the use of one or more vocabularies which may be optionally described using RDF Schema. (See also the RDF Primer [RDF-primer] section 6.7 on "Describing Device Capabilities and User Preferences".)
As CC/PP is vocabulary neutral, it allows different vocabularies to be developed and implemented by communities involved in developing applications, devices and browsers. It also allows for the dynamic composition of a delivery context profile from fragments of capability information that may be distributed among multiple repositories on the web.
CC/PP is the preferred approach to communicating delivery context information between clients, intermediaries and origin servers. It is the basis for UAProf, which is currently used to express the capabilities of many mobile devices. There are a number of implementations available [CCPP-implem] which consume CC/PP profiles, and there is also a Java Community Process interface definition for profile consumers [JSR188].
The current CC/PP Recommendation [CCPP-struct-vocab] provides a structure and a sample vocabulary based on the version of RDF current during its development. It is expected to be brought up to date with the latest revisions of RDF [RDF-concepts] and RDF Schema [RDF-schema], and to be extended to include support for capabilities asserted by intermediate proxies and gateways. Further work is also required to specify a protocol for exchanging CC/PP profiles, and to specify how a profile should be processed and used within any mechanism for content adaptation. See Section 5 for further details of ongoing work.
The Open Mobile Alliance (OMA, formerly the WAP Forum) has defined a User Agent Profile [UAProf] as an implementation of CC/PP for WAP-enabled mobile terminals, providing convergence of mobile web technologies with those of the Web.
WAP 1.2.1 recommends transporting UAProf information over the Internet using the HTTP Extension Framework [HTTPex] which was originally suggested for CC/PP [CCPP-exchange]. WAP defined the WSP protocol, which includes a compressed encoding, for use between the phone and the gateway onto the Internet. Due to the lack of implementations of HTTPex, WAP 2.0 instead defined an extension of HTTP 1.1 as an Internet protocol (W-HTTP) that uses custom headers.
The WAP Forum also defined a UAProf vocabulary, based on CC/PP, that includes hardware and software characteristics as well as WAP specific features of the mobile terminal and associated transport network. Subsequent updating, to UAProf V2.0, by OMA has based the definition on the latest version of RDF and RDF Schema.
WURFL , [WURFL], is a free, open source project that provides an alternative source of information to UAProf. It tries to provide a comprehensive resource of device information, and contains device information for 4500 variants of devices. Because WURFL is open source, anyone can correct device information, not just device manufacturers. WURFL provides its own XML format for device characteristics description.
In W3C recommendations, such as CSS and HTML, style markup can be made conditional on delivery context by using Media Queries [MQ]. These introduce another vocabulary for accessing device characteristics.
Media Queries build upon the use of 'media types' as defined in CSS2 [CSS2], which allow styles to be conditional on a number of named categories of device: aural, braille, embossed, handheld, print, projection, screen, tty and tv. In Media Queries, device characteristics ('media features') may be queried and combined using a restricted expression syntax. The style used to present an element of HTML, XHTML or XML can therefore be made conditional on the characteristics of the delivery device. By making use of the CSS 'display' property, it is also possible to conditionally include or exclude complete elements from the presentation.
In the future, it should therefore be possible to add device-dependent styling to common device-independent content, at least as far as the CSS media types and media features will allow.
Like CSS, Media Queries are typically expected to be processed directly in user agents, based on local delivery context information. However, they could also be fully or partially processed at servers or intermediaries in the response path, based on delivery context information passed as part of a request for content. This highlights the need for the vocabulary used for the device capabilities passed in the delivery context to correspond to the vocabulary used within Media Queries.
A further W3C standard, the Synchronized Multimedia Integration Language (SMIL) introduces yet another vocabulary for accessing a limited number of device characteristics.
SMIL 2.0 [SMIL] is defined as a set of markup modules that can be integrated into specific language profiles. In particular, it defines a BasicContentControl Module that defines certain system characteristics that may be used to control a SMIL presentation. These characteristics may be given dynamic values according to the runtime environment. Like Media Queries, they therefore allow a user agent that supports dynamic SMIL characteristics to access local delivery context information.
System test characteristics included as part of the SMIL BasicContentControl Module cover presentation-related capabilities such as screen size, network bandwidth, and text and audio captions, as well as system-related characteristics such as CPU and operating system identity.
The following approaches have been proposed, but have not been widely implemented to date.
Transparent Content Negotiation [TCN], was first proposed as an experimental protocol in RFC 2295.
Transparent negotiation uses both HTTP server-driven and agent-driven negotiation mechanisms (as described in Section 4.2), together with a caching proxy that supports content negotiation. The proxy requests a list of all available representations from the origin server using agent-driven negotiation, then selects the most appropriate and sends it to the client using server-driven negotiation. However, this technique has not been widely implemented.
The IETF Content Negotiation working group [Conneg] focused on defining the features which could form the basis for negotiation. In particular, in RFC 2506, a procedure was defined for registering Media Feature Tags in a central Internet Assigned Numbers Authority (IANA) registry.
A further result of the Conneg work was a proposal for combining Media Features Tags into Media Feature Sets [MFS]. In RFC 2533, a syntax for expressing Boolean combinations of features is proposed and an algorithm for feature set matching (see also [FSM]) is also described.
ISO/IEC is defining the MPEG-21 [MPEG-21] framework which is intended to support transparent use of multimedia resources across a wide range of networks and devices. The fundamental unit of distribution is the 'digital item', which is an abstraction for some multimedia content with associated data.
One aspect of the requirements for MPEG-21 is Digital Item Adaptation which is based on a Usage Environment Description (see section 4.7.2 in [MPEG-21-req]). It proposes the description of capabilities for at least the terminal, network, delivery, user, and natural environment, and notes the desirability of remaining compatible with other recommendations such as CC/PP and UAProf.
While existing techniques provide some basic support for delivery context information, there are a number of areas that remain to be addressed. The W3C Device Independence Working Group (DIWG) is chartered [DI-charter] to carry out further work on delivery context and its use in web authoring.
The W3C Delivery Context Workshop held in March 2002 [DCW] gave an opportunity for presentation and discussion about technologies associated with device independent delivery, and delivery context in particular. The workshop identified a number of areas relating to delivery context where further work was necessary.
For example, among some of the topics discussed were:
For further details see the position papers, presentations and workshop notes.
This remainder of this section summarizes the areas of ongoing work within DIWG and the issues that are currently being addressing.
The current W3C recommendation for representing delivery context information is CC/PP, as described in Section 4.3.
Some aspects of the original proposals of the CC/PP working group were omitted in the current recommendation due to lack of implementation experience. These include support in the profile for describing the capabilities of transcoding proxies, which may in some cases extend the effective capabilities of a device. For example, they may allow a wider range of image formats to be accepted in an HTTP response from a server, since the proxy can transcode them into an image format accepted by a particular device.
It has already been mentioned that a revised version of CC/PP is under consideration that would make fuller use of the latest version of RDF. In particular, RDF now supports the explicit association of data values with their data type. This has the potential to allow CC/PP profiles to be more self-describing, in that type information about capabilities would no longer need to be defined in an RDF schema that was separately conveyed to the profile consumer.
In order to implement the interoperable exchange of delivery context information, it is necessary to specify how the information is conveyed as part of a request protocol. Apart from the use of HTTP headers to express some limited aspects of delivery context as described earlier, no consensus has been reached on how more general delivery context information can be conveyed.
A proposal was made for a protocol for CC/PP based on the HTTP Extension Framework [CCPP-exchange], but in practice this framework has not been widely implemented.
UAProf [UAProf] has defined a protocol based on additional ad hoc HTTP header fields.
However, there is still a need to standardize an extensible way of conveying delivery context, beyond the existing header fields, as part of an HTTP 1.1 request.
Protocol design is non-trivial. Care must be taken, especially if it is to affect many web requests, not to introduce inefficiencies. For example, to minimize additional use of network bandwidth, a protocol should encourage optimizations such as indirect reference to static parts of the context information or caching of unchanging characteristics. A protocol should also allow intermediaries, if necessary, to access and augment the contextual information with minimal overhead.
Session-based management of context could be considered, complementing the widely implemented HTTP state management using cookies, as described in RFC 2965. If delivery context information were associated with a session, it might not be necessary to convey the full context with each request. Instead, it might be possible to simply notify changes from the previous context data.
Further work on CC/PP Protocol is included in the charter of the Device Independence Working Group [DI-charter]. This will focus on a protocol for use with conventional stateless HTTP requests. Work on session-based protocols is out of the current scope.
It is not sufficient simply to define how delivery context information can be conveyed as part of a communication protocol. For the end-to-end semantics of the delivery process to be well defined and predictable, it is also necessary to consider how the context information is resolved and made available to the adaptation or negotiation mechanisms at the different points in the delivery chain described in Section 3.
Profile information could be distributed across multiple locations on the web. It may not be consolidated and made available all in one place. For example, a hardware manufacturer and a software provider may make the static capabilities of their respective parts of an access mechanism available on their own websites, whereas network capabilities may depend on the routing of a particular request. So it should be possible to retrieve distributed capability information and compose or derive the delivery context at any appropriate point in the delivery path. To do this flexibly, a delivery context should be able to use combinations of characteristics from multiple vocabularies, or multiple versions of a single vocabulary, that relate to different aspects of an access mechanism. For example CC/PP uses XML namespaces to distinguish characteristics from different vocabularies.
Since a delivery context may be built from characteristics provided by different components along the delivery path, it should be possible to accumulate delivery context information provided by different components. The means of accumulation could simply consist of appending the information from different sources in separate profiles, or of combining them into a single profile. It should not be assumed that any particular component along the path is capable of resolving the information further.
Resolution rules can be used to describe how characteristics may default or override. However, if different rules are created for different characteristics, the complexity of the resolution process can quickly grow. Resolution mechanisms may be specific to each application, or application independent resolution mechanisms may be used for all applications that depend on the same profile. For example the UAProf standard specifies application independent resolution rules.
Processing rules are also necessary to define the behavior of processing sequences such as a client, an intermediary acting as a proxy and an origin server. Here the client device and the proxy may provide different versions of the same characteristics, so it is necessary to disambiguate. Similarly, there may be a need to deal with aggregated devices, such as connecting a phone and PDA in order to provide voice and text browsing. Here one of the devices may merge the profiles from the phone and the PDA in order to allow the server to provide a multimodal interface. In this case it is necessary to determine which of the client devices, and possibly which modality or other grouping on that device, provides a particular characteristic.
Delivery context characteristics must also fit into authoring and adaptation environments, and allow individual characteristics to be accessed as part of page adaptation on origin servers as well as by intermediaries and clients.
In DIWG, it is intended to cover CC/PP processing at the same time as work on CC/PP protocol, since the two are closely related in their implementation.
Delivery context information is expressed in terms of values of characteristics which may be drawn from, and are defined in, one or more vocabularies.
In the overview of existing and proposed approaches, it is clear that many groups have started to define vocabularies that could be used to express aspects of delivery context. For device capabilities alone, there are already Media Features defined in the IANA registry as part of the Conneg work, different versions of the UAProf vocabulary defined by the Open Mobile Alliance, Media Queries as part of CSS style, system characteristics in SMIL, and an example CC/PP vocabulary.
Vocabularies for delivery context characteristics need to be standardized so that authoring and adaptation processes can use them in a consistent fashion to select or generate suitable user experiences.
It is inevitable that vocabularies for characteristics will evolve through a number of different versions. It is also likely that they will need to incorporate characteristics that have been defined in other approaches for other purposes, as illustrated in the range of potential characteristics described in Section 1.1. There is a danger that vocabularies and their versions may proliferate so that the task of interpreting them and making appropriate adaptations to delivered content becomes unmanageable.
It should be possible to declare a set of characteristics as a vocabulary that can be combined with other vocabularies for other characteristics. By sharing sets of characteristics between vocabularies, it should be possible to minimize the number of different characteristics that might be introduced for essentially similar capabilities. CC/PP, by being based on RDF, naturally supports such definition and re-use.
It is preferable to re-use characteristics whenever possible during vocabulary definition. However, it may also be possible to separately identify equivalences between characteristics from different vocabularies at a later date. The Web Ontology Language [OWL] provides a means both for defining the properties and classes that might make up a vocabulary as well as making explicit the relationships, such as disjointness and equivalence, there might be between them.
Some of the markup languages referred to in Section 4 already provide mechanisms for authors to refer to delivery context characteristics when creating web pages. In particular, CSS Media Queries and SMIL introduce ways of referring to a limited set of characteristics. CSS is intended to be used for adding styling information to other markup languages, such as XHTML and SVG, and so allows delivery context dependent styling to be expressed in a uniform way for the languages which incorporate it, at least for the few characteristics it defines. The set of characteristics introduced by SMIL is also small, and defined in a way specific to that language.
In anticipation of the need to express content selection for web pages that is dependent on delivery context, a draft proposal has been produced by DIWG for a context-dependent way of expressing Content Selection [DI-sel]. In particular, this advocates the potential use of XPath or RDF Query to access delivery context information, using modular markup that could be incorporated in other languages such as Modular XHTML.
The Delivery Context Interfaces (DCI) work being developed by DIWG defines a platform independent API for accessing delivery context information. The interface allows mechanisms to both query and update properties. For dynamic properties, it is important to be able to respond to changes when they occur, consequently a mechanism to subscribe and unsubscribe to events is provided. The DCI is designed to allow for properties to be defined by different organizations. The Open Mobile Alliance (OMA) has developed a set of properties for describing static characteristics of mobile phones. Device vendors are expected to define additional properties for proprietary features.
A set of XHTML Document Profile Requirements were proposed in 1999 [XHTML-docprofile]. These could be seen as complementary to delivery context characteristics, in that they could potentially define document characteristics that would be required in order to successfully deliver a document.
This leads to considering the broader use of metadata, created as part of document authoring, as a means of guiding the adaptation of content for a particular delivery context. At the time of writing, W3C is about to hold a Workshop on Metadata for Content Adaptation to explore this topic further.
While it is not the purpose of this document to identify specific requirements, it is useful to collect together some remaining open issues, beyond the work described in the previous section.
It may be useful to identify the source of delivery context information provided by different components along the delivery path, and to extract the information from the delivery context provided by each source.
By identifying the source of some delivery context information, it may be possible to do a better job of adapting the content. For example, a request for printed output made via a phone may include device capabilities for the printer (so that the output can be formatted for it) as well as for the phone (so that any print control or error messages can be displayed on it). It is important that these can be distinguished and separately extracted.
In addition, it may be important for assessing the reliability of the delivery context information, or the trust to be placed in it, for its source to be identified.
If document metadata (as mentioned in Section 5.6), or some similar mechanism, is used to describe the capabilities required of the delivery device, there needs to be a way of matching this to the delivery context information so that appropriate content can be delivered.
With the modularization of markup languages such as XHTML, SVG, CSS and SMIL, a mechanism is also required for representing and negotiating which modules are supported by a user agent and which modules are required to successfully deliver a document. For example, the 3GPP specification for Packet Switched Streaming service [3GPP-PSS], which is based on SMIL, defines its own vocabulary for capability exchange based on UAProf and includes a means of enumerating supported SMIL modules.
Several techniques have been proposed to perform capability negotiation between devices: for example SyncML for data synchronization or the Wireless Village Initiative for instant messaging - both of these are now consolidated into the Open Mobile Alliance.
Since delivery context could be used to convey user-specific information, it is important to consider how much trust the user can place in how that information is handled. Ultimately this could extend to providing security measures for ensuring the privacy of sensitive information.
An early working draft of CC/PP Implementors Guide on Privacy and Protocols [CCPP-trust] includes a discussion on privacy issues within the CC/PP framework, including examples of how the recommendations of the Platform for Privacy Preferences Project [P3P] could be used with CC/PP. It also includes an Appendix on "Basic requirements for trust management frameworks".
Issues that relate to trust include:
Many of these issues are beyond the scope of device independence. If limited information about device and network capabilities can be freely shared, the user can benefit from receiving content better suited to the delivery device. This is the case currently, for example, in the use of HTTP header information. However, if such capability information is withheld, the user should still be provided with a functional user experience.
However, it is necessary to consider the potential misuse of any characteristics that are provided in good faith in order to achieve a better user experience, and to balance this against the benefits. Ultimately, the user should be given control over whether user experience-related characteristics are made available by a user agent as part of the delivery context. In addition, it may be necessary to include in the delivery context itself, or in the definition of its processing, rules that indicate what may or may not be changed or acted on by intermediaries.
This document has focused on delivery context in a traditional Web delivery environment. In other words, the focus has been on the conveying of delivery context information from a client to a server, via possible intermediaries, using HTTP.
However, the general principles may be applicable to other environments using other protocols. For example, Multimodal Interaction and Web Services use alternatives to, or extensions of, HTTP. However, they both have the need to describe the characteristics of the context into which they are delivering the results of web requests.
In particular, even if the details of conveying delivery context information in a particular protocol may differ, the representation of that information, and the vocabularies on which it depends, may be shared across many environments. The benefits of re-using the syntax and semantics of device and other delivery context characteristics in different environments are greater interoperability and reduced implementation costs.
Delivery context information may be useful across a wide range of distributed application domains, and not least for achieving device independence for the Web. In this domain, it provides the key information on which better adaptation of content across different access mechanisms must depend.
This document has provided an overview of progress in representing and using delivery context for this purpose. The W3C Device Independence Working Group is chartered to continue work on further topics in this area.
Members of the W3C Device Independence Working Group have helped develop this Working Group Note through their comments, proposals and discussions at teleconferences, face-to-face meetings and via the group discussion list.
At the time of publication, the principal and active members of the group were as follows:
The following were members of the group at earlier stages of its drafting:
Since the last version, the document underwent changes to reflect client and server side adaptation. The role of delivery context was clarified with regard to adaptation and content access. Diagram 3.1 was changed to reflect client side context access. An introduction to DCI work was provided. DCI was added as a possible candidate for device delivery context access mechanisms.


The following section is dedicated exclusively to wave scripts. We'll go over special functions and the arena object. As you can now create projectiles from the encounter as well, information about projectiles and their examples have been moved to the API - Projectile management section.
The Arena object [W]
You can use this object to obtain information about the arena, resize it or move it.
Don't forget that the Arena's position is reset at the beginning of the next wave!
Arena.width (readonly) - the width of the arena in pixels, after resizing. Since the reference for the player and bullets is the arena's center, you can get the left/right side of the arena with -Arena.width/2 and Arena.width/2 respectively.
Arena.height (readonly) - the height of the arena in pixels, after resizing. Like with width, you can get the bottom/top with -Arena.height/2 and Arena.height/2 respectively.
Arena.x (readonly) - the x position of the center of the Arena, after resizing.
Arena.y (readonly) - the position of the bottom of the Arena, after resizing. To get that of the center, just do Arena.y + Arena.height/2.
Arena.currentwidth (readonly) - the current width of the arena in pixels. Differs from width in that it will accurately reflect the arena size in the middle of resizing, too.
Arena.currentheight (readonly) - the current height of the arena in pixels. Differs from height in that it will accurately reflect the arena size in the middle of resizing, too.
Arena.currentx (readonly) - the current x of the arena in pixels. Differs from x in that it will accurately reflect the arena position in the middle of moving, too.
Arena.currenty (readonly) - the current y of the arena in pixels. Differs from y in that it will accurately reflect the arena position in the middle of moving, too.
Arena.isResizing
(readonly) - Tells you if the Arena is currently being resized.
: There's an equivalent of this in 0.2.1a - just use
Arena.currentwidth ~= Arena.width or Arena.currentheight ~=
Arena.height.
Arena.isMoving (readonly) - Tells you if the Arena is currently being moved.
Arena.isModifying (readonly) - Returns true if the Arena is being moved or resized, false otherwise.
sprite Arena.inner (cannot be set) - Inner sprite of the arena.
sprite Arena.outer (cannot be set) - Outer sprite of the arena.
Arena.rotation Rotation of the arena. Rotating the arena will not change the soul's movement direction.
Arena.Resize( width, height) Resizes the arena to the new size. Currently, entities stay below of the arena.
Arena.ResizeImmediate( width, height) Resizes the arena instantly, without the animation.
Arena.Move( x, y, movePlayer = true, immediate = false) Moves the Arena based on its current position. Set movePlayer to true if you want the Player to move with the Arena and set immediate to true if you want to move the Arena immediately.
Arena.MoveTo( x, y, movePlayer = true, immediate = false) Moves the Arena based on the bottom-left corner of the window. Set movePlayer to true if you want the Player to move with the Arena and set immediate to true if you want to move the Arena immediately.
Arena.MoveAndResize( x, y, width, height, movePlayer = true, immediate = false) Moves the Arena based on its current position and resizes it at the same time. Set movePlayer to true if you want the Player to move with the Arena and set immediate to true if you want to move the Arena immediately.
Arena.MoveToAndResize( x, y, width, height, movePlayer = true, immediate = false) Move the Arena based on the bottom-left corner of the window and resizes it at the same time. Set movePlayer to true if you want the Player to move with the Arena and set immediate to true if you want to move the Arena immediately.
Arena.Update() Function used to update the arena's library. It shouldn't be used, but it's there for transparency.
EndWave() [W]
Ends this wave immediately. You can only call this function from the Update function.
wavename [W]
Returns the name of the wave file, without the extension, from the Waves folder.


|
My Project
|
#include <dbformat.h>
Public Member Functions | |
| InternalFilterPolicy2 (const FilterPolicy *p) | |
| virtual | ~InternalFilterPolicy2 () |
| Public Member Functions inherited from leveldb::InternalFilterPolicy | |
| InternalFilterPolicy (const FilterPolicy *p) | |
| virtual const char * | Name () const |
| virtual void | CreateFilter (const Slice *keys, int n, std::string *dst) const |
| virtual bool | KeyMayMatch (const Slice &key, const Slice &filter) const |
| Public Member Functions inherited from leveldb::FilterPolicy | |
| FilterPolicy () | |
| virtual | ~FilterPolicy () |
| const FilterPolicy * | GetNext () const |
| void | SetNext (const FilterPolicy *Next) const |
Additional Inherited Members | |
| Protected Attributes inherited from leveldb::InternalFilterPolicy | |
| const FilterPolicy *const | user_policy_ |
| Protected Attributes inherited from leveldb::FilterPolicy | |
| const FilterPolicy * | m_Next |
|
inlineexplicit |
|
inlinevirtual |


HTTP Access Control
Learn how to configure access to Puppet’s HTTP API using the rest_authconfig
file, a.k.a. auth.conf
. This document is currently being checked for accuracy. If you note any errors, please email them to<EMAIL_ADDRESS>HTTP
Puppet master and puppet agent communicate with each other over a pseudo-RESTful HTTP network API. By default, the usage of this API is limited to the standard types of master/agent communications. However, it can be exposed to other processes and used to build advanced tools on top of Puppet’s existing infrastructure and functionality. (HTTP API calls are formatted as https://{server}:{port}/{environment}/{resource}/{key}
.)
As you might guess, this can be turned into a security hazard, so access to the HTTP API is strictly controlled by a special configuration file.
auth.conf
The official name of the file controlling HTTP API access, taken from the configuration option that sets its location, is rest_authconfig
, but it’s more frequently known by its default filename of auth.conf
. If you don’t set a different location for it, Puppet will look for the file at $confdir/auth.conf
.
You cannot configure different environments to use multiple rest_authconfig
files.
File Format
The auth.conf file consists of a series of ACLs (Access Control Lists); ACLs should be separated by double newlines. Lines starting with #
are interpreted as comments.
# This is a comment
path /facts
method find, search
auth yes
allow custominventory.site.net, devworkstation.site.net
# A more complicated rule
path ~ ^/file_(metadata|content)/user_files/
auth yes
allow /^(.+\.)?example.com$/
allow_ip <IP_ADDRESS>/24
# An exception allowing one authenticated workstation to access any endpoint
path /
auth yes
allow devworkstation.site.net
Due to a known bug, trailing whitespace is not permitted after any line in auth.conf in versions prior to 2.7.3.
ACL format
Each auth.conf ACL is formatted as follows:
path [~] {/path/to/resource|regex}
[environment {list of environments}]
[method {list of methods}]
[auth[enthicated] {yes|no|on|off|any}]
[allow {hostname|certname|*}]
Lists of values are comma-separated, with an optional space after the comma.
Path
An ACL’s path
is interpreted as either a regular expression (with tilde) or a path prefix (no tilde). The root of the path in an ACL is AFTER the environment in an HTTP API call URL; that is, only put the /{resource}/{key}
portion of the URL in the path. ACLs without a resource path are not permitted.
Environment
The environment
directive can contain a single environment or a list. If environment isn’t explicitly specified, it will default to all environments.
Method
Available methods are find
, search
, save
, and destroy
; you can specify one method or a list of them. If method isn’t explicitly specified, it will default to all methods.
Auth
Whether the ACL matches authenticated requests.
auth yes
(oron
) means this ACL will only match requests authenticated with an agent certificate.auth any
means this ACL will match both authenticated and unauthenticated requests.auth no
(oroff
) means this ACL will only match requests that are not authenticated with an agent certificate. Authenticated requests (like from puppet agent) will skip this ACL.
Most communications between puppet agent and the puppet master are authenticated, so you will usually be using auth yes
.
The value of auth
must be one of the above options; it cannot be a list. If auth isn’t explicitly specified, it will default to yes
.
allow
The node or nodes allowed to access this type of request. Can be a hostname, a certificate common name, a list of hostnames/certnames, or *
(which matches all nodes). If the path for this ACL was a regular expression, allow
directives may include backreferences to captured groups (e.g. $1
).
An ACL may include multiple allow
directives, which has the same effect as a single allow
directive with a list.
Behavior in 0.25.x through 2.7.0: No fine-grained globbing of hostnames/certnames is available in allow directives; you must specify exact host/certnames, or a single asterisk that matches everything.
Behavior in 2.7.1 and later: Hostnames/certnames can also be specified by regular expression. Unlike with path directives, you don’t need to use a tilde; just use the slash-quoting used in languages like Perl and Ruby (e.g. allow /^[\w-]+.example.com$/
). Regular expression allow directives can include backreferences to regex paths with the standard $1, $2
etc. variables.
Any nodes which aren’t specifically allowed to access the resource will be denied.
allow_ip
Note: The
allow_ip
directive was added in Puppet 3.0.0. Previous versions of Puppet cannot allow nodes by IP address.
An IP address or range of IP addresses allowed to access this type of request. Can be:
- A single IP address
- A glob representing a group of IP addresses (e.g.
192.168.100.*
) - CIDR notation representing a group of IP addresses (e.g.
<IP_ADDRESS>/24
)
Any nodes which aren’t specifically allowed to access the resource will be denied.
Deny
A deny
directive is syntactically permitted, but has no effect.
Matching ACLs to Requests
Puppet composes a full list of ACLs by combining auth.conf with a list of default ACLs. When a request is received, ACLs are tested in their order of appearance, and matching will stop at the first ACL that matches the request.
An ACL matches a request only if its path, environment, method, and authentication all match that of the request. These four elements are equal peers in determining the match.
Matching Paths
If an ACL’s path
does not start with a tilde and a space, it matches the beginning of the resource path; an ACL with the line:
path /file
…will match both /file_metadata
and /file_content
resources.
Regular expression paths don’t have to match from the beginning of the resource path, but it’s good practice to use positional anchors.
path ~ ^/catalog/([^/]+)$
method find
allow $1
Captured groups from a regex path are available in the allow directive. The ACL above will allow nodes to retrieve their own catalog but prevent them from accessing other catalogs.
Determining Whether a Request is Allowed
Once an ACL has been determined to match an incoming request, Puppet consults the allow
directive(s). If the request was unauthenticated, reverse DNS is used to determine the requesting node’s hostname; the request is allowed if that hostname is allowed. If the request was authenticated, the certificate common name is read from the SSL certificate, and the hostname is ignored; the request is allowed if that certname is allowed.
Consequences of ACL Matching Behavior
Since ACLs are matched in linear order, auth.conf has to be manually arranged with the most specific paths at the top and the least specific paths at the bottom, lest the whole search get short-circuited and the (usually restrictive) fallback rule be applied to every request. Furthermore, since the default ACLs required for normal Puppet functionality are appended to the ACLs read from auth.conf, you must manually interleave copies of the default ACLs into your auth.conf if you are specifying any ACLs that are less specific than any of the default ACLs.
Default ACLs
Puppet appends a list of default ACLs to the ACLs read from auth.conf. However, if any custom ACLs have a path identical to that of a default ACL, that default ACL will be omitted when composing the full list of ACLs. Note that this is not the same criteria for determining whether the two ACLs match the same requests, as only the paths are compared:
# A custom ACL
path /file
auth no
allow magpie.example.com
# This default ACL will not be appended to the rules
path /file
allow *
These two ACLs match completely disjoint sets of requests (unauthenticated for the custom one, authenticated for the default one), but since the mechanism that appends default ACLs is not examining the authentication/methods/environments of the ACLs, it considers the one to override the other, even though they’re effectively unrelated. Puppet agent will break if you only declare the custom ACL, will work if you manually declare the default ACL, and will work if you only declare the custom one but change its path to /fil
. When in doubt, manually re-declare all default ACLs in your auth.conf file.
The following is a list of the default ACLs used by Puppet:
# Allow authenticated nodes to retrieve their own catalogs:
path ~ ^/catalog/([^/]+)$
method find
allow $1
# allow nodes to retrieve their own node definition
path ~ ^/node/([^/]+)$
method find
allow $1
# Allow authenticated nodes to access any file services --- in practice, this results in fileserver.conf being consulted:
path /file
allow *
# Allow authenticated nodes to access the certificate revocation list:
path /certificate_revocation_list/ca
method find
allow *
# Allow authenticated nodes to send reports:
path /report
method save
allow *
# Allow unauthenticated access to certificates:
path /certificate/ca
auth no
method find
allow *
path /certificate/
auth no
method find
allow *
# Allow unauthenticated nodes to submit certificate signing requests:
path /certificate_request
auth no
method find, save
allow *
# Deny all other requests:
path /
auth any
An example auth.conf file containing these rules is provided in the Puppet source, in conf/auth.conf.
Danger Mode
If you want to test the HTTP API for application prototyping without worrying about specifying your final set of ACLs ahead of time, you can set a completely permissive auth.conf:
path /
auth any
allow *
Note Make sure any testing configurations using this pattern do not make it to production systems.
authconfig / namespaceauth.conf
Older versions of Puppet communicated over an XMLRPC interface instead of the current HTTP interface, and access to these APIs was governed by a file known as authconfig
(after the configuration option listing its location) or namespaceauth.conf
(after its default filename). This legacy file will not be fully documented, but an example namespaceauth.conf file can be found in the puppet source at conf/namespaceauth.conf.
puppet agent and the HTTP API
If started with the listen = true
configuration option, puppet agent will accept incoming HTTP API requests. This is most frequently used to trigger puppet runs with the run
endpoint. Several caveats apply:
- A known bug in the 2.6.x releases of Puppet prevents puppet agent from being started with the
listen = true
option unless namespaceauth.conf is present, even though the file is never consulted. The workaround is to create an empty file:# touch $(puppet agent --configprint authconfig)
- Puppet agent uses the same default ACLs as puppet master, which allow access to several useless endpoints while denying access to any agent-specific ones. For best results, you should short-circuit the defaults by denying access to
/
at the end of your auth.conf file.


Caveat is a handwriting type family designed by Pablo Impallari. It is designed for both short annotations and body text usage. For a different style, there is also a sister family, Caveat Brush
The fonts have OpenType features that enable the letters to have slight variations according to their occurrence within a word, for a natural handwritten feel.


We made this app to quantify the amount of misogynistic language used by individual hip hop artists. Type in the name of an MC and we’ll assess their lyrics based on what’s on Rapgenius.com. Having crunched the propotion of misogynistic language (including terms like bitch, ho, etc), we’ll report it back to you in an easy-to-read score.
It’s not an acid test, but it should provide a rough indicator of what to expect when you’re listening to a new artist.  Now you can use this app to spot the sexist MCs in advance. We hope you find it useful.


I use my raspberry with oemgateway to collect data from rfm12b and send to my local server (with emoncms) and to emoncms.org, and all work fine.
yesterday I modified oemgateway to push data only to my local server and I modified my local emoncms to load data on emoncms.org; so in this case my local emoncms receives data from oemgateway and not from rfm12b.
I observed that in this case local emoncms did not upload data to remote emoncms; in my opinion this problem depends from process that collects data from rfm12b, that when receive data, it upload to remote emoncms. so in my case it does not receive any data from rfm12b, so it never upload oemgateway's data to emoncms.org
ps my local emoncms tell me "Authentication successful" about emoncms.org
problem sending data from my local emoncms to remote emoncms.org
Submitted by modenet on Fri, 23/08/2013 - 14:10I use my raspberry with oemgateway to collect data from rfm12b and send to my local server (with emoncms) and to emoncms.org, and all work fine.
yesterday I modified oemgateway to push data only to my local server and I modified my local emoncms to load data on emoncms.org; so in this case my local emoncms receives data from oemgateway and not from rfm12b.
I observed that in this case local emoncms did not upload data to remote emoncms; in my opinion this problem depends from process that collects data from rfm12b, that when receive data, it upload to remote emoncms. so in my case it does not receive any data from rfm12b, so it never upload oemgateway's data to emoncms.org
ps my local emoncms tell me "Authentication successful" about emoncms.org


Delivering projects that fulfill and exceed the owners expectations is
a process that starts during the conceptual stage with a collaborative
team from design to construction.
This integrated team
approach puts the focus of all team members specifically towards the
culmination of the completed project. Check out our projects by
clicking on the categories below.


[1]
i will give this hotel obviously needs some.
[2]
i will give this hotel obviously needs some attention.


Last year, I presented an approach to wrapping C++. Since then, I’ve been introduced to other approaches, particularly from gf who helped me better understand opaque objects. Since I do a lot of cross-language work, I’ve had some opportunity to play with and expand this, and so I’d like to update my C++ wrapping approach.
First, to remind everyone of the problem: you have a C++ object that you want to consume in Objective-C. That’s easy in ObjC++, but if you make an ivar that references a C++ class, then the header file can only be included by ObjC++ classes. This quickly spreads .mm files throughout your project, creating all kinds of headaches. ObjC is a beautiful thing, and C++ is fine, but ObjC++ is a crazy land that should be carefully segregated from civilized code. So how do we do it?
We create a thin wrapper object to provide an ObjC face on a C++ object. The challenge is how to hide C++ classes from the header file. The answer is to put them in a struct that you forward declare so you don’t have to expose its contents. Structs are almost identical with C++ classes, but their forward declaration syntax is C-compatible (unlike class). Let’s look at how this is done.
For this example, we will consider a C++ class called RN::Wrap
. It holds a simple string with set and get accessors.
class Wrap {
public:
Wrap(string str) : m_string(str) {};
string getString() { return m_string; };
void setString(string str) { m_string = str; };
private:
string m_string;
};
We wrap this into Objective-C++ using an opaque structure, RNWrapOpaque
:
struct RNWrapOpaque;
@interface RNWrap : NSObject {
struct RNWrapOpaque *_cpp;
}
Since we only include a raw pointer to RNWrapOpaque
, we don’t have to declare anything else about it in the header file. If we tried to store the actual struct here (rather than a pointer), then that would defeat the purpose. This is the only raw pointer we will need.
Since structs are almost identical to classes in C++, we can use class features like constructors and destructors in the implementation (.mm file):
struct RNWrapOpaque {
public:
RNWrapOpaque(string aStr) : wrap(aStr) {};
RN::Wrap wrap;
};
Now initializing and using the opaque object is easy in ObjC++ code:
- (id)initWithString:(NSString *)aString {
self = [super init];
if (self != nil) {
self.cpp = new RNWrapOpaque([aString UTF8String]);
}
return self;
}
- (void)dealloc {
delete _cpp;
_cpp = NULL;
[super dealloc];
}
- (void)setString:(NSString *)aString {
self.cpp->wrap.setString([aString UTF8String]);
}
- (NSString *)string {
return [NSString stringWithUTF8String:
self.cpp->wrap.getString().c_str()];
}
A nice side effect of this usages is that C++ objects are easy to detect through the self.cpp
prefix. Memory management is easy since there is only one raw C++ pointer.
Using the class requires no special work. It’s pure ObjC:
RNWrap *wrap = [[[RNWrap alloc] initWithString:@"my string"] autorelease];
NSLog(@"wrap = %@", [wrap string]);
In part two, we’ll discuss how to extend this approach to more complex problems such as smart pointers, listeners/delegates, and bindings.


The Swirling Vortex Behind Me...
Well, I live in Berkeley, which is very close to San Francisco. I'd heard a lot about Salvia, but from what I understood, it was kind of hard to get your hands on and also a bit on the expensive side. Anyways, I went to Haight-Ashbury one day and was surprised to see that head shops were selling it for about $3 for a small baggie. Of course, I bought some just to see what all the hype was about.
When we got back later that evening, my friend and I decided to fire it up. We went outside onto my patio where it was nighttime and there was some light from the moon. Mixing it in a 1:1 ratio with weed, we put it in the bowl of the bong and smoked it. After a couple of minutes, I felt a bit more paranoid than I typically am while high. After a few minutes, I wasn't absolutely positive that I could attribute my feeling to the Salvia (it was kind of subtle), but I knew that I normally didn't feel this.
Then, I felt something that was quite scary - and although I remember telling myself that it was completely irrational to be scared of it - I couldn't shake the feeling.  Of course, when I turned around, there was nothing there - but as I was looking behind me, it suddenly felt like it was behind me on the other side (always behind my eyes, perpetually out of view, where I could never see). My friend noticed my unease and told me to relax. I was uncomfortable and a little paranoid for a while, but really that was it. My friend didn't get the same experience, he just said he was in an unusually contemplative state for a few minutes.
Another friend of mine later told me that she had the same experience as me (she didn't know about my experience when she did it, though). Anyway, it was a mildly frightening experience, but I basically dismissed it as my mind's fear of the unknown, or fear of what I couldn't see....
I've done it a few more times with similar but less frightening results. Salvia is OK, I'd do it again, but honestly, I don't really get a lot from it, entheogenically speaking. Give it a shot if you want - I don't think it was anything that scarred me for life. :)
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Section 2.7 User's Guide
Skills Addressed in this Lesson:
Enter the User Guide through the Options Menu.
Read the table of contents within the User Guide.
From within the User Guide, enter the index.
Access an item from the table of contents.
Access an item from the index options.
Read the items in the User Guide as desired.
Follow the BrailleNote prompts in the User Guide as necessary.
Exit the User Guide.
Subsection 2.7.1 Tasks
Instruct your student to enter the User Guide. He or she should do this by first going to the options menu with space and o. Then press a u to enter the User Guide.
Your student may be given a cue such as "continue reading alarm?" Press an n for no.
A cue such as "press t for table of contents or i for index" should be displayed. Your student should press an i for index.
Read through the items in the index by using space. Use backspace to move back by item. The back and advance thumb-keys will also move back and forward by index item.
Explore the index items. The initial letter of an item can be used to jump directly to an index item.
-
Move to the index item called "battery" and press enter. The following commands can be used to read when in the User Guide index. Practice reading about the battery.
To start auto-advance, press space with dots1 2 4 5 6.
To start continuous speech, press space with g.
To return to the index, press backspace.
Space with e will exit the User Guide.
To move by subsection, press space with dots4 5 6 or space with dots1 2 3.
Space with dot1 and space with dot4 will move by sentence.
To move by paragraph, use space with dots5 6 and space with dots2 3.
Exit the User Guide. Return to the Main Menu.
From Main Menu, open the User Guide. At the cue, continue reading about the battery, press n for no.
-
At the cue, press t for table of contents. Use the commands below to read through the table of contents items.
Space or backspace will move forward and back by item.
Space with e will return to the table of contents.
Enter on the item you wish to read.
 Sub-index items will then be given.
Move to and from sub-indexes in the usual manner. Press enter on a sub-index item you would like to read.
Your student may use the same commands to read the table of contents as he or she did to read the index.
When your student is finished, return to the Main Menu and turn the BrailleNote off. Provide time for practice and exploration within the User Guide because it's a great way to learn!
Subsection 2.7.2 Quiz
Copy each sentence. Fill in the blank with the correct answer. Use the BrailleNote to complete the written work.
To start ? press space + dots12456.
Enter the User Guide through the ? menu.
To move by ? use space + dots23 and space + dots56
Space + ? will exit the User Guide.
In the User Guide you can read by ? or ?
Press ? to go into an index item.
To get help in the User Guide, press ?
To enter the User Guide, press space + o followed by ?
Press space + dot1 or space + dot4 to move back or forward by ?
? is the last item in the User Guide index.


# Introduction
If you follow me on twitter or github, you may have seen this new neuron coming, otherwise, let me introduce to you the [Google Maps neuron](https://github.com/bacardi55/kalliope-gmaps) :)
The goal as you can guess is to leverage the Google Maps API to get direction, distance or direction from an origin point to a destination (it doesn't handle multi origin or destination yet).
# What can you do ?
* Ask for the address of a place (eg: "what is the address of the Eiffel tour")
* Ask for the distance / time between 2 places. (how far is "address A" from "Address B")
* Ask for the directions between 2 places, on top of distance/time. (how to go from "Address A" to "Address B")
The synapse has a lot of options, so you can set your transportation mode (driving, walking, tube, …), the language, the units system, …
Read the [readme file](https://github.com/bacardi55/kalliope-gmaps/blob/master/README.md) as it contains more information (and more up to date).
# Installation
## Neuron
Usual neuron installation:
Will install the neuron and the [google maps services python library)[https://googlemaps.github.io/google-maps-services-python/docs/2.4.5/)
## Synapse
Get the distance and time between 2 locations
Get the address of a place by its name
You can find more up to date example on the [github readme page](https://github.com/bacardi55/kalliope-gmaps/blob/master/README.md)
## template
Here is a single template file to handle multiple use cases:
Of course, you can simplify by splitting it into several templates depending on the arguments you send.
# What's next
Obviously, the Gmaps API is so rich that the possibility for this neuron are limitless… But at least this first version let you do the basics…
What I have in mind for next updates:
* multi origin / destination
* Leverage more API from google maps
As always, ideas or pull requests are more than welcome!


Gateway
BOT
05-Jun-19 11:51 AM
[telegram] <lion_musk> Rf...hNMN
[telegram] <CryptoBattler> What did you try? (re @Ruediger_von_der_Hohenlohe: Ok I give up... None of the alternatives given is working!  You don't want that
[telegram] <Ra> What a big mess this is , an early fix is hoped
[telegram] <CryptoBattler> use https://veruscoin.io/wallet.html (re @Ruediger_von_der_Hohenlohe: Verus lite on linux and windows, verus native is slow and chamaleon won't let me import kmd via wif or I'm to stupid to find the option to do so)
Community driven open source CPU mineable cryptocurrency with 50/50 Proof-of-Work/Proof-of-Stake, zk-SNARK zero-knowledge proof privacy.
[telegram] <Ruediger_von_der_Hohenlohe> Yes I don't want the native download ^^
[telegram] <Crypto> If funds were moved to another adress that this one «RSgD2cmm3niFRu2kwwtrEHoHMywJdkbkeF» it means we got hacked ?
[telegram] <Seifert> In the form, Address to receive can i provide new Ledger address or it has to generated via agama v (re @CryptoBattler: Your funds are safe)
[telegram] <Ruediger_von_der_Hohenlohe>
[telegram] <Ruediger_von_der_Hohenlohe> I tried... So should I send my kmd via the old agama to a new address? because none of the given things is working easily.
[telegram] <Ruediger_von_der_Hohenlohe> Verus just shows me the error given above on the picture
[telegram] <CryptoBattler> safe address: RSgD2cmm3niFRu2kwwtrEHoHMywJdkbkeF RWXmNq2EgDgknZs2uaJ3ETs2nnhwqczAtQ seems to be intermediate address (re @Crypto: If funds were moved to another adress that this one «RSgD2cmm3niFRu2kwwtrEHoHMywJdkbkeF» it means we got hacked ?)
[telegram] <CryptoBattler> First check to see if your address has been swept by the dev team https://dexstats.info/assetviewer.php (re @Seifert: In the form, Address to receive can i provide new Ledger address or it has to generated via agama v)
Check your Address Balances on KMD Assetchains
[telegram] <Ruediger_von_der_Hohenlohe> ok
[telegram] <Ovidiu> Same error here
[telegram] <CryptoBattler> Have you tried changing servers? (re @Ruediger_von_der_Hohenlohe: )
[telegram] <Crypto> No it’s another adress (re @CryptoBattler: safe address: RSgD2cmm3niFRu2kwwtrEHoHMywJdkbkeF RWXmNq2EgDgknZs2uaJ3ETs2nnhwqczAtQ seems to be intermediate address)
[telegram] <CryptoBattler> What's your address, I'll have a look (re @Crypto: No it’s another adress)
[telegram] <Seifert> Can i use new ledger nano address ? (re @Seifert: In the form, Address to receive can i provide new Ledger address or it has to generated via agama v)
[telegram] <Ruediger_von_der_Hohenlohe> Yes, same problem (re @CryptoBattler: Have you tried changing servers?)
[telegram] <Ovidiu> Me too
[telegram] <Ovidiu> New server unreachable
[telegram] <CryptoBattler> when logging in, you need to select 'VRSC' not kmd in Lite mode (re @Ruediger_von_der_Hohenlohe: Verus just shows me the error given above on the picture)
[telegram] <Crypto> RDGbSFhDrjyFj6ZXwcQEhgdunTGd7WbxNU
[telegram] <CryptoBattler> Which coin are you selecting? (re @Ovidiu: New server unreachable)
[telegram] <Crypto> Thanks a lot (re @CryptoBattler: What's your address, I'll have a look)
[telegram] <Ovidiu> I started VRSC lite mode and than i activated KMD also in lite mode
[telegram] <Ovidiu> Versu is ok Kmd gives me the error shown in the picture
[telegram] <CryptoBattler> Your funds are safe (re @Crypto: RDGbSFhDrjyFj6ZXwcQEhgdunTGd7WbxNU)
[telegram] <CryptoBattler> You don't need to activate kmd. send it to the VRSC address and you'll be fine (re @Ovidiu: I started VRSC lite mode and than i activated KMD also in lite mode)
[telegram] <jessecouch> Does anyone know the answer to this? https://twitter.com/jessecouch/status/1136233023987277826
Does anyone know which derivation address (ex. m/44'/141'/0'/0/0) is used to get these wallets from the seed? Thanks.
@KomodoPlatform @0xca333 @siddhartha_cryp @Jl777News @redfoxlabs_io
[telegram] <Ruediger_von_der_Hohenlohe> Now that is the actual problem :D I don't know how to send it without beeing able to use agama (re @CryptoBattler: You don't need to activate kmd. send it to the VRSC address and you'll be fine)
[telegram] <Crypto> Awesome news, so what should we do now ? (re @CryptoBattler: Your funds are safe)
[telegram] <Ovidiu> Can i also send my rfox tokens and pirate?
[telegram] <Seifert> Can one clarify this pls ? (re @Seifert: In the form, Address to receive can i provide new Ledger address or it has to generated via agama v)


Email Verified !
It's safe to close window
Please navigate to the app and click on done to get started.


Register A
cc
ount
Preferred Pronoun
Choose here
{{pronoun}}
Gender
Choose here
{{gender}}
Complete Sign Up
pick your home
coffee shop


BLAST FROM THE PAST
Reviewed by Harvey Karten, Ph.D. New Line Cinema Director: Hugh Wilson Writer: Bill Kelly, Hugh Wilson Cast: Brendan Fraser, Alicia Silverstone. Christopher Walken, Sissy Spacek, Dave Foley
When I taught high-school social studies during the ealry sixties, we followed the curriculum, which mandated that we teach a unit on fifth-century B.C. Greece. Each term we asked our 15-year-olds whether they would have preferred to live in Athens (a center of intellectual ferment) or Sparta (a military dictatorship), and each term we got the same knee- jerk answer, "Athens." Perhaps the kids were giving us what they thought we wanted to hear. After all we were college- educated, and the Athens of the time was chock full of philosophers, playwrights and artists. One youngster impressed me, though. His answer: "Sparta--because I would not have to think." Good one! The choice is not such a no-brainer, after all, since we remember that Athens had a large population of slaves and of women who had no political rights, while Sparta's lifestyle was suited to the love that Americans still had for the military during the Kennedy administration.
Sharp teachers now propose a more contemporary question: would you rather live in America during the early 1960s or now? Eyes would roll as youngsters who have seen New Line Cinema's "Pleasantville," would recall a preceding population of repressed women and rigidly conformist males, liberated by hip siblings David and Jennifer. No problem guessing their response. But think again. Remember that during the repressed sixties small-town America was safer, more secure, more predictable, and comparatively free of drugs, crime, and AIDS. How does that take us to New Line's current offering? "Blast from the Past" is "Pleasantville" turned topsy-turvy. Instead of a couple of 90's kids freeing the psyches of the folks from the 50s and 60s, this time a fellow from the innocent 60s shows up our contemporary society by his superior manners, education, and morality.
"Blast from the Past," whose title comes from an expression by a celebrated deejay who'd introduce rock-and- roll classics with that expression, has a double-meaning. It stands in for the nuclear devastation which one family believes occurred in 1962, and also for the emergence of a 35-year-old man who wiled away his youth with just his mom and dad for company and had about as much idea of what was going on in the real world as did the Val Kilmer character in "Sight Unseen." When Calvin Webber (Christopher Walken) and his wife Helen (Sissy Spacek) hear JFK's TV address pitting the U.S. toe-to-toe against the Soviet Union over the Cuban mssiles, they take to their California underground bomb shelter, a spacious abode boasting a thirty-five year stockpile of food and other needs. Because (incredibly enough) they did not have a radio or TV in the shelter, they could not have known that the Soviets backed down. Hearing a devastating explosion just above their shelter (actually a crashing plane which levels their home), they assume it to be a nuclear discharge. Helen gives birth to a baby boy, and the threesome settle in for a thirty-five year span, expecting to emerge when California would become safe from radioactive fallout. The highly educated Calvin and his wife teach the boy languages, math, science, dancing, and the art of self-defense, so that when he ultimately emerges above ground, he would be prepared for life among society. What happens when the 35-year-old Adam (Brendan Fraser) ascends and meets the modern world--especially Eve (Alicia Silverstone) with whom he falls in love--is the source of great fun and no small amount of social satire.
Adam compares the people he meets with his own family and decides that they have become mutated from the bomb. And no wonder. One man shifts through garbage while another throws up in the street. What was once a fruit orchard is now the home of a porn parlor. The community is full of strip malls and boarded-up stores. He overcomes his repulsion for post-nuclear humankind when he falls in love and, as is the custom in any good romantic comedy, the ardent couple must be kept apart until the end of the movie. This feat is accomplished by Eve's unwillingness to believe that a guy so polite, so caring, so well-mannered can be real, and by her inability to accept his naively boyish behavior.
Director Hugh Wilson milks the story for social commentary, indicating the decline and fall of Western civilization from 1962 to 1999. As a microcosm of history, he centers on Mom's Malt Shop which during the seventies turns into a disco bar and ultimately into a bikers' saloon. But "Blast from the Past" is, fortunately, no exercise in cerebral inquiry but a wonderfully inventive, original comedy with good acting all around. Christopher Walken shines as the eccentric Cal Tech professor-turned-inventor who has the foresight to lock his family into the underground shelter for over three decades, with Sissy Spacek his hand-wringing and not altogether accepting wife. The thirty-one-year old Brendan Fraser continues to surprise his public with his breadth, having turned in a crackerjack performance as a Neanderthal youth in modern society in "Encino Man" and recently as a guest in the home of horror-meister James Whaley in "Gods and Monsters," knocking out a fine appearance as straight- man to Ian McKellen's idiosyncratic gay director. There's a neat side role by Dave Foley as Troy, Eve's gay brother, who is particularly sympathetic to Adam's fish-out-of-water predicament and serves as Cupid to coax her sister into Adam's arms. The showstopping scene occurs on the dance floor of the Club 40, where Adam naturally stands out, vigorously and expertly taking on a couple of beautiful women in some exuberant period steps. "Blast from the Past" is solid entertainment without a dull moment, good fun, and an effective rejoinder to "Pleasantville"'s championing of modern times.
Rated PG-13. Running Time: 106 minutes. (C) 1999 Harvey Karten
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


Healthcare Proffessional &
Certified Innovation Professional
Welcome to Haya Balasmeh Biography
Play Guess Game
About Us
Home


Yes. The web browser does not pay any attention to spaces or new lines (except inside <pre> and </pre>.
Some Web authors prefer to create their tables in the style of the question. Web design tools (such as Dreamweaver usually produce HTML that looks like that. They use indenting to show the role of the text on each line. Here is a nice table:
| Barium | Yellow |
| Boron | Green |
| Sodium | Yellow |
| Strontium | Red |
Edit the following to create the table:


I am a span
I am the first span in div
I am the second span in div
First div inside div
Second div inside div
I am the third span in div
I am the fourth span in div
I am the first span outside div
I am the second span outside div
I am the first span in div
I am the second span in div
I am the first span outside div
I am the second span outside div


Take the role of an Agent in a secret organization, and complete missions with the aid of a unique time-manipulation device: You can JUMP your MIND into your body throughout the timeline.
MINDJUMP was a project for my Narrative Design class. This was a solo project, so I was responsible for all aspects.
A full-length, expanded and improved version of MINDJUMP is currently in development.


| Modifier and Type | Field and Description |
|---|---|
static int |
DST_THRESHOLD
Distance used to calculate a square cost near a ghost.
|
static double |
EMPTY_COST
The cost when you go to empty square (no pellet).
|
static double |
GHOST_COST
The cost when you go to a square where there is a ghost.
|
static double |
NEAREST_GHOST_COST
The cost when you go to a square nearest to a ghost.
|
static double |
PELLET_COST
The cost when you go to a square where there is a pellet.
|
| Constructor and Description |
|---|
AStarPath(Game game)
Default Constructor.
|
| Modifier and Type | Method and Description |
|---|---|
java.lang.Double |
g(Square originSquare,
Square destinationSquare)
Determines the cost of the square (used to define the best square).
|
protected java.util.List<Square> |
generateSuccessors(Square square)
Determines the square neighbors.
|
static java.util.List<Square> |
getValidNeighbors(Square square)
Get the list of valid neighbors (accessible to a player).
|
java.lang.Double |
h(Square originSquare,
Square destinationSquare)
Determines the distance between from and to square.
|
boolean |
isGoal(Square square)
Test to know if the square is the goal or not.
|
static double |
manhattanDistance(double x,
double y,
double a,
double b)
Compute the manhattan distance
between a point (x,y) and a point (a,b).
|
boolean |
nearestGhosts(Square destinationSquare)
Check if the square is nearest to a square with a ghost.
|
void |
setGoal(Square goal)
Determines the goal square.
|
public static final double GHOST_COST
public static final double NEAREST_GHOST_COST
public static final double PELLET_COST
public static final double EMPTY_COST
public static final int DST_THRESHOLD
public AStarPath(Game game)
game
- The game.public static double manhattanDistance(double x, double y, double a, double b)
x
- the x coordinate from first point.y
- the y coordinate from first point.a
- the x coordinate from second point.b
- the y coordinate from second point.public static java.util.List<Square> getValidNeighbors(Square square)
square
- the player square.public final boolean isGoal(Square square)
public void setGoal(Square goal)
goal
- the goal square0public final java.lang.Double g(Square originSquare, Square destinationSquare)
public final java.lang.Double h(Square originSquare, Square destinationSquare)
public final boolean nearestGhosts(Square destinationSquare)
destinationSquare
- the square to check.protected final java.util.List<Square> generateSuccessors(Square square)
generateSuccessors
in class AStar<Square>
square
- The current square.


$ gem install asciidoctor
Edgar Allen Poe
Sheri S. Tepper
Bill Bryson
Edgar Allen Poe
Sheri S. Tepper
Bill Bryson
Edgar Allen Poe
Sheri S. Tepper
Bill Bryson
level 1
level 2
level 3
level 4
level 5
level 2
Every list item has at least one paragraph of content, which may be wrapped, even using a hanging indent.
Additional paragraphs or blocks are adjoined by putting a list continuation on a line adjacent to both blocks.
a plus sign (+
) on a line by itself
A literal paragraph does not require a list continuation.
$ gem install asciidoctor
checked
also checked
not checked
normal list item