All developers are familiar with the acronym "CRUD" which stands for "create, read, update, and delete." Traditional development projects involve putting in place the components necessary to accomplish these four tasks. You may start with a development framework that makes it easy to get a working system running that accomplishes CRUD. Even I can create a Rails app that does basic CRUD in an afternoon. CRUD applications usually join the ranks of other single-purpose silos of data and functionality in the lonely world of who cares. A few lucky ones break out of their silos through APIs or web services and make friends with other applications, but these apps are just loaning each other their CRUD capability. They are the mayors of the world of who cares.

The Kynetx platform has modified the meaning of CRUD. Instead of create, read, update, and delete we have:

• Context: intent + location + relationship = omniscience
• Rules: creative capacity codified
• User: master of all she surveys
• Delivery: endpoint ubiquity

In order to understand what Craig Burton calls the Tao of KRL you need to grok the new CRUD. In order to understand 4th party applications as described by Phil Windley you need to grok the new CRUD. It's the key. It's the future.

Here's a little bit more to chew on:

Context is what we use to guide our interactions and relationships with individuals. If we are astute we gather context from every credible source available. Context is more than demographics: it's intent, relationships, mood, location (both physical and virtual), history, preferences, and opinions. Context is knowing. Context starts with the simple get-to-know-you questions that you ask when you first meet someone and can be as complex, nuanced, and mature as a 60-year marriage relationship. Kynetx is a powerful platform for gathering context.

Rules determine what we do with that context. Rules define the events that we watch for, the conditions we evaluate, and the actions we take when those events and conditions are met (AKA an event-condition-action, or ECA system). The advantage of Kynetx is the fact that you can listen for a significant number of different events, and that number will increase over time. Events can be things like accessing a web page, meeting a data threshold, initiating a relationship, or walking into a store, among many others. Conditions can be just as varied as events. Actions include things like annotate search results, data integrations, and content aggregations.

The User is the center of the universe with Kynetx apps. The user decides what apps they want to use, what data they provide. Kynetx apps give the user a new mechanism for controlling their internet experience. In the case of 4th party applications, users are the focus of every other party in the system.

Delivery is accomplished through endpoints. Kynetx is starting with browser-based endpoints, but will move out to other systems. Endpoints live where the user lives. Endpoints listen for events that are written into Kynetx apps and trigger application evaluations.

When developers understand the new CRUD available in the Kynetx platform they are liberated from the old CRUD and can build new, interesting things. Ultimately, Kynetx is a way to program the Internet and any Internet-connected endpoint.

The first Web service that Amazon put up, years ago, was the ECommerce API that allowed API access to Amazon's product information. That API has gone through several name changes and is now called the Product Advertising API. Thousands of people have used this API to add data about products--and the opportunity to buy them--to their Web sites.

That's the problem, of course. You can use it on your Web site, but you can't conveniently use them in a browser extension to build client-side community apps because your Amazon developer keys would be exposed to the world. The most recent build of KRL changes that by making the Amazon Product Advertising API (PAA) available as a library. That means that it's possible to use Kynetx to build client-side applications that use the PAA without exposing your developer tokens. That opens up a whole host of possible uses for Amazon product information that were difficult to achieve before.

Here's a video that shows this at work:

Of course, to create client-side applications that people will install and use requires more than just pumping more product at them. The KRL integration of PAA includes the ability to access all the user-generated reviews, product information, photos, and other product data that would allow a developer to create a first-rate experience that adds real value for people who download and use their apps.

KRL makes using PAA easy. To get started, you simple put your Amazon developer secrets and associate ID in the meta block of your application:

meta {
  key amazon {
    "token"        : "absjj99a9ad9ad8799",
    "secret_key"   : "absjj99a9ad9ad87799absjj99a9ad9ad8799",
    "associate_id" :  "windleyofente-20"
  }
}

These are stored securely in the cloud and not divulged to users of the application.

The KRL Amazon library has two primary methods: ItemSearch and ItemLookup. With ItemSearch the search index is a parameter and additional parameters depend on the particular index. ItemLookup takes an Amazon product ID (ASIN) as it's primary parameter. Here's an example:

amazon:item_lookup({"ItemId" : "B00008OE6I",
                "response_group" : "ItemIds" })

The response is returned as JSON so that you can use JSONPath to pick it apart and use it. Here's a piece of the response to the previous query:

"Item" : {
            "OfferSummary" : {
               "LowestUsedPrice" : {
                  "Amount" : "3999",
                  "CurrencyCode" : "USD",
                  "FormattedPrice" : "$39.99"
               },
               "TotalRefurbished" : {},
               "TotalUsed" : "8",
               "TotalCollectible" : {},
               "TotalNew" : {}
            },
            "ASIN" : "B00008OE6I"
         }

Here's a video showing a little more about how this is done and giving a working example.

You can install the example that we used for the first video or just view the source code using the app detail page in the Apps Directory.
Here's the documentation for the Amazon library.

The Amazon integration with KRL allows Amazon developers to build client-side application that use Amazon product data without exposing the Amazon developer credentials--something that's been hard in the past. KRL is designed to make using online data like Amazon or Twitter easy and quick. We'll be annnouncing some other major data and service integrations over the next few weeks as we gear up for Kynetx Impact in April. Come join us.

Doc Searls uses the term "sewage pump" (I'm paraphrasing) to describe the modern advertising-based economy. Modern society has created the most efficient machine imaginable to push stuff at people whether they want it or not. I gave an example in this blog post about Novatel: they're treating Twitter as a way to push stuff at me instead of as a place to relate to me.

A pump pushing sewage at you is a good metaphor for what's wrong with the marketplace we've constructed in the late 20th century. Doc has built the VRM project as a means of exploring better ways of building markets for the 21st century. Something I hadn't considered until I was going through David Siegel's book Pull is that "pull" is the right metaphor for this new marketplace and it's precisely why Doc's metaphor of a sewage pump rings so true.

David's book is about the Semantic Web and the use of data standards to enable you to "pull" the information, services, and products to you. An example from the book that really hit home for me is this: in 2010 if you order a package from Amazon, you have to give an address where it will be delivered. Wouldn't it be better if instead, you just gave Amazon an identifier and then the package would find you at the place you wanted it to go--even if that's the hotel you're currently staying at? In essence, you pull the package to you with online data. This isn't a pipe dream, but a perfectly reasonable way to think about how the world ought to work--and one that's doable now from a technical standpoint.

Doc uses different language to describe this same idea when he talks demand leading supply. The pump is all about supply leading demand. The key idea that both Doc and David would agree on here is that "If demand leads supply..., customers need to be the points of integration for their own data." More on that later.

The Four Party System

In an effort to further define VRM, Doc has introduced the notion of "fourth-party services." He says:

Among numbered parties the best-known one today is the third party. Wikipedia currently defines a third party this way (at least for the computer industry):

• Third-party developer, hardware or software developer not directly tied to the primary product that a consumer is using
• Third-party software component, reusable software component developed to be either freely distributed or sold by an entity other than the original vendor of the development platform

In general, a third party works on the vendor's side of the marketplace. However, the vendor is not generally called the "first party" (except in the game business, as Wikipedia says here). In fact, the most common use of the term "first party" in business is with insurance, where the term refers to the insured. (The insurer is the second party.)

From » VRM and the Four Party System ProjectVRM
Referenced Fri Feb 26 2010 11:04:37 GMT-0700 (MST)

So, if third-party services are merchant driven, it stands to reason that the customer-drive services that represent them would be the fourth party.
Here's a picture of these four parties:

The little horseshoe magnet looking things are called rel buttons are meant to represent customers or merchants (left and right in the above diagram) who want to relate to each other.

Fourth-party services, be theysimple or sophisticated will act as brokers that work on the user's behalf to manage their interaction with vendors of various products and services. Without such automated agents, no one would want to take on the work that would be necessary otherwise to manage the dozens of relationships each of us has with vendors. But with them magic happens.

Building 4th Party Apps

Doc and David are both thinking about very general solutions to this problem as well they should. My job, as the CTO for Kynetx, however, is slightly different. I'm trying to build things for our customers and make them work now. The Kynetx platform has always been aimed at creating client-side Web applications that help users achieve a purpose. That's a pretty good working definition of "fourth-party" in my book. The platform is designed to allow developers to use data in context to create interesting Web applications. Moreover, our corporate philosophy has been consistently in favor of respecting user rights to control data.

With that backdrop, I've thought long and hard about how Kynetx could be used in service of VRM and--by David's definition--the semantic web. I'll use this schematic to help explain my latest thinking:

To keep this simple, I'm going to avoid going down every "or they could do..." fork in the tree. There are lots of them. Here's the flow:

1. The user visits a merchant. This could be online or in person (imagine the app running on their phone and using location in context).
2. At the same time any fourth party apps that they've installed (denoted by the fourth-party rel-button) are invoked as long as they are relevant to the current activity.
3. KNS (the Kynetx Network Service) executes the rules associated with the presented apps. We're going to presume for sake of this example that those apps need personal data to work on the user's behalf and such access has not been previously granted.
4. KNS requests the required user information from the personal data store (PDS).
5. The user is asked to authorized such access and grants it.
6. The PDS requests the data from various sources as necessary and returns it to KNS. Note that as envisioned here, the PDS acts more like a virtual directory than an actual repository, although that's not a strict requirement.
7. KNS executes any relevant merchant rules (determined by the app, current context, and the data retrieved in step 6) to determine how they want to relate. Merchant rules are denoted by the third-party rel-button in the diagram. This may be specific offers, discounts, special service levels, etc. I'm calling this "the deal" for lack of a better word.
8. Finally the results are presented to the user's client.

A key feature of the scenario shown in the figure is the privacy wall (in red). That's there to reinforce the fact that in this model the user's data is never given to the merchant. The merchant's rules act against it, but they never see it. For fourth-party apps to work, users will need assurance that their data is being treated in a way that respects privacy. They will also need to trust the agents working on their behalf.

A few other points to note:

• Kynetx has no access to user data except as authorized by the user. The user is entirely in control of the experience and what data is used.
• The merchant rules could exists in a standard rule format like RuleML and be stored in any repository so long as they were discoverable.
• The same holds for user data. There's no need for it to be in a single place as long as it's in standard formats, is discoverable, and has a clear, unambiguous meaning. David calls this same concept the personal data locker and it is central to the whole idea of the semantic web, pull, and VRM.
• As envisioned the merchant rules, users data, and user apps are all orthogonal to each other. This isn't a single application, but a platform where fourth-party apps can be built using whatever user data and merchant rules are available.
• Successful fourth-party apps won't just be ways to get offers to customers but manage the relationship between merchants and users in sophisticated ways. They could, for example store receipts, initiate and mediate support issues, manage returns, and so on.
• In this demo, we're using OAuth to enable user control of the data in the PDS but that's really a stand-in for other more versatile standards that are forthcoming like UMA and R-Cards.
• The scenario above focuses on one interaction where the app and the merchant rules could conduct a complete, complex negotiation on the user and merchant's behalf. Keep in mind, however, that the key is the relationship and that is bigger than a singleton deal or negotiation and might include support and service functions, ratings, and so on. Successful fourth-party apps will be seen by users as trusted agents, not merely a way to get a good deal on a single transaction.

A key difference between this model and a traditional ad network is the idea of "pull." Ads are not being pushed (note that successful pushing requires "tracking" and "targeting" users--niether is being done here). Rather more holistic information about what I'm calling "deals" is being pulled to the user based on their purpose and intent.

I have a working demo of all of this right now that uses a PDS that has access to a user's Amazon wish lists as an example of intent data and Acxiom-held data as an example of personal data--all under user control. Getting from demo to production is more a legal and business matter, not a technical one. We're working on that too. I plan to share this demo and the ideas and techniques behind it at the Kynetx Impact conference in April and at IIW X in May.

The inclusion of intent data in the demo is important because data that signals user intent or purpose is much more useful in creating compelling fourth-party apps than mere facts like gender or household size that leave the app to infer intent. Guessing will become less necessary because users will have convenient, private means of sharing intent. In this model, attention gives way to intention just as purpose gives way to location.

Some might complain that there's too much dependence on KNS or that KNS is closed. That's not technically true: Kynetx is proprietary, not closed. Still, if that bothers you, give me the standards and we'll use them. We're all about building support for standard data sources and formats into the system. As I mentioned above, I'm open to supporting rules expressed in RuleML or some other standard format. And, of course, no one is imagining that KNS would be the only system doing this. This is just our contribution to making the idea of VRM and fourth-party services real.

We invite your participation. Signup for a free developer account. Register for Impact where you can listen to Jon Udell's keynote and discuss these ideas with us. We're happy to listen, resolve issues, and make this work.

Kynetx is on the forefront of creating the app-driven purpose-centric web. As we talk to people about our platform I have discovered that there are two main categories of Internet users:

Category 1: Placers- as in users who think about the Internet only as a collection of locations. Placers are firmly rooted in the paradigm of location. You go to an address, you visit a site, etc. They consider web sites analogues to physical stores or your front lawn. Most people are placers because they have only been exposed to server-delivered/browser-consumed web applications, which reinforce placer thinking. You can’t blame a placer for being a placer.

When placers see what can be done with Kynetx applications their initial reaction usually includes two sentiments: the first being, “that’s really cool,” and the second being, “the site owner won’t like it.”

Category 2: Appers- as in users who think about the Internet as a platform for building interesting applications. Appers can separate location from application, and can appreciate the organization of data and functionality from different sources to bring new value. Appers are not averse to trying new apps in their client environments. Ultimately they know they are in control of their experience. Appers are relatively rare, but mobile platforms are converting more people to this kind of thinking, and the markets are recognizing this coming shift. This shift is inexorable on all platforms, including the server-centric web.

When appers see their first Kynetx demo they get very excited and always want to sign up for a developer account on our platform. They frequently make statements where they compare Kynetx favorably to such ideas as sliced bread.

Phil Windley coined what I will call the Apper’s Creed:

I claim the right to mash-up, remix, annotate, augment, and otherwise modify Web content for my purposes in my browser using any tool I choose and I extend to everyone else that same privilege.

Put in other terms, the Apper's Creed asserts the right to run apps in the browser environment. I believe that more and more people will discover the value that appers enjoy and will make the transition from the placer world.

A very important question for Kynetx application developers is: how do we get placers to begin to make the transition to appers? Another important question: how do our apps get along with location-centric resources and developers on the Internet?

I will explore answers to those two questions in a series of weekly posts. I hope you find them useful.

February 24, 2010, SALT LAKE CITY

— Jon Udell author, information architect and new media innovator,
will headline the Kynetx Impact Conference in Salt Lake City April
27-28, 2010. Udell will review the Net's original peer-to-peer
architecture, and explore why it matters more than ever.

The conference will highlight Kynetx Network Services technology that
supports this movement and will show how these new capabilities have
the potential to re-shape the future of user experience the Web.

The Kynetx platform helps developers create applications that span
multiple URLS and devices in response to user context, giving users
more control of their web experience. Since last year, Kynetx
developers have created more than 900 of these new platform-
independent applications, with many more slated to enter the market
through 2010.

“De-centralization was a core value of the initial Internet, but it’s
an aspect that has largely been lost,” Udell maintains. “The Kynetx
platform helps us bring it back.”

Since 2007, Udell has served as a writer, speaker and presenter for
Microsoft. His calendar syndication service, http://elmcity.cloudapp.net, runs on Azure -- Microsoft's new
cloud platform -- and exemplifies the decentralized Web architecture
that he has always championed. From 2002 to 2006 Udell was InfoWorld’s
lead analyst, author of the weekly Strategic Developer column, and blogger-in-chief. His 1999 book, Practical Internet Groupware, helped lay the foundation for what we now call social software.

The conference will also feature presentations from Dr. Phil Windley, Kynetx co-founder, and identity and technology
lexicon expert Craig
Burton. The cost is just $150 to attend the Kynetx Impact
Conference. The event will offer workshops that teach attendees how to
create new power applications with the proprietary Kynetx rules-based
platform. For more information, visit www.kynetx.com
.

About Kynetx

Founded in 2007, Kynetx is a private company that has developed a
development platform for applications that understand and respond to
user context across any web-enabled device. Developers and
businesses can use this platform to quickly mash up data, functions
and interface points in order to create the next era of software
services and Internet applications.

Incident Summary:

The KNS platform experienced a service interruption at 1740 MST, which lasted for a five (5) minute period. This outage was attributed to a memory starvation issue on the master load balancer in the load balancing cluster, which caused a failover of the cluster. The failover was successful, but took longer than normal (tested) due to the contributing memory issue.

Services Impacted:

• Evaluation Servers (cs.kobj.net)
• Initialization Servers (init.kobj.net)
• Callback Serves (log.kobj.net)

Root Cause Analysis:

The root cause was identified as a memory starvation issue on lb1.kob.net. The load balancer cluster has been very stable since installation,and there is no reason to suspect that there will be any further service issues.

Recovery Steps:

Once alerted by monitoring and customer reports, a manual forced failover/failback was performed by the Kynetx IT Operations team. This action restored service and returned control of the cluster to the master, who had recovered from the memory starvation issue. Going forward, the Kynetx IT Operations team will schedule a maintenance window to increase the amount of memory allocated to the load balancer processes. Service was restored in less than five (5) minutes from first alert.

The latest build of the Kynetx Rule Language (KRL) provides a significant upgrade in capability with the addition of functions. We've also added some new array operators that take advantage of functions to make using arrays easier.

KRL supports functions as first-class objects in the expression language. KRL supports only anonymous functions, but they can be given names by binding them to a variable in a declaration. Here's an example:

pre {
  add5 = function(x) {
           x + 5
         };
}

Functions are evaluated statically (e.g. the environment they are defined in, not the environment they are executed in determines the binding of free-variables) and can be recursive. Here's an example of a recursive function in KRL:

pre {
  fact = function(n) {
            (n <= 0) => 1
                      | n * fact(n-1)
         }
}

Functions are declared using the keyword function and contain optional declarations followed by a single expression that returns the result of the function when executed. To see this,
consider the following example which uses Newton's method to calculate square roots (taken from Section 1.1.8 of Structure and Interpretation of Computer Programs):

sqrt = function(x) {
    average = function(x,y) { (x + y) / 2 };
    good_enough = function(guess, x) {
       v = (guess * guess) - x;
       v < 0.01 && v > -0.01
    };
    improve = function(guess, x) {
       average(guess, (x / guess))
    }
    sqrt_iter = function(guess, x) {
       good_enough(guess, x) => guess
                              | sqrt_iter(improve(guess,x), x)
    };
    sqrt_iter(1.0, x)
}

Functions can return functions as values and functions can be passed as the arguments to other functions and operators in KRL. The following example defined a generalized summation function that sums the numbers from a to b incrementing using inc and applying the function f to each term:

sum = function(f, a, next, b) {
  (a > b) => 0
           | f(a) + sum(f, next(a), inc, b)
};
inc = function(x) { x + 1 };
cube = function(x) { x * x * x };
sum_cubes = function(a, b) {
  sum(cube, a, inc, b)
}

We could define a function that creates incrementor functions. When given a number, it returns a function that increments by that value:

inc_generator = function(n) { function(x){ x + n } };
inc = inc_generator(1);
inc_by_2 = inc_generator(2);
inc_by_25 = inc_generator(25);

Being able to write functions adds significant power. More so with some of the other languages changes we have in mind for the next few months.

Weve also added several new array operators in recent builds. Most notably, array references now work as follows:

a = [1,4,3,6,5];
b = a[1]

This would bind the value 4 to the variable b. Note that array references only work for arrays of one-dimension, so c[1][2] is not allowed (presuming c is an array of arrays).

In addition, there are a number of new operators available for arrays.
The following array operators are now available (in addition to length which has been previously available):

• sort - sorts the array. With no argument, sorting is done in ascending order. The argument "reverse" causes sorting to happen in descending order. The argument can also be a function that takes two argument and returns a boolean value which will be used as the comparison function for the sort.
• filter - filters an array, producing a new array. The operator takes a function argument that takes a single parameter and returns a boolean value. The return array contains elements for which the function returns true.
• map - modfies an array from mapping a function to each member of the array. The operator takes a function argument that takes a single parameter and returns any value. The array returned from map is the result of applying the function to each member of the original array in turn, collecting the results into a new array.
• head - returns the first element of an array without modifying the array.
• tail - returns an array that is identical to the orginal array except without the first member.

You could use these like so:

pre {
  f = function(x) { x < 4 };
  g = function(y) { y * 2 };
  a = [1,4,3,6,5];

  b = a.sort(); // returns [1,3,4,5,6]
  c = a.filter(f); // returns [1,3]
  d = a.head(); // d has the value 1
  e = a.map(g); // e has the value [2,8,6,12,10]
}

Operators are fairly easy to add and handy to have, so if you have ideas for other operators, on arrays, strings, and so on, just let us know.

From this point forward, you must only use qualified (e.g. namespaced) functions in predicate positions (like referer:search_engine_referer()). The documentation has been updated to reflect these changes.

LEHI, Utah, January 22, 2010--(BUSINESS WIRE)--Kynetx is leading the client-side revolution with its unparalleled development platform and program. At the heart of the platform is a rules-based language that allows developers to build entirely new web experiences that are cross-site, cross-platform and respond to context in the user’s environment. By leveraging this unique platform, the Kynetx developer program has already garnered more than 300 developers resulting in over 800 applications.

“Unlike any other platform, Kynetx offers developers the technology to easily resolve data mismatches coming from fractured sources of information. This capability results in a new breed of apps that act as powerful context-aware mash-ups,” says Stephen Fulling, Kynetx co-founder and CEO. “Information is only powerful if it touches you when and where you need it…in context. Kynetx gives developers the tools they need for connecting the dots.”

Richard Miller, a lead developer at FamilyLink.com, used the Kynetx Development platform to create a prototype application with the power to extend FamilyLink’s functionality to sites across the web, including Facebook, Gmail, LinkedIn, and Twitter. In just a few days, he crafted the prototype application that extends the experience of FamilyLink users when looking for relatives, adding relatives or communicating with them beyond the FamilyLink site.

“This is exactly the kind of viral growth and entrepreneurial innovation we were hoping would come out of our Developer Program,” Fulling continued. “Richard read a blog post about us, signed up, and was writing a ground-breaking app in minutes. The Kynetx Developer Program offers unparalleled tools and infrastructure to help unleash developers’ imaginations. Clearly, that’s what Richard Miller has done.”

Kynetx recently increased its “mash-up” capabilities with new Twitter API support. The Kynetx Rules Language now integrates with the Twitter API, using Twitter’s OAuth scheme, giving developers the ability to create Kynetx applications that can easily access Twitter data.

“The Twitter upgrade opens a myriad of possibilities for our Developer Program,” says Dr. Phillip Windley, Kynetx CTO. “Using Kynetx, you can create and deploy an app in minutes that understands and responds to Twitter data on any website or web-enabled device.”

Kynetx also offers semi-annual conferences designed for developers to explore ideas and learn from the experts, face to face. The next Kynetx Impact conference is scheduled for April 27th-28th in Salt Lake City. More information and registration can be found at www.kynetx.com.

To sign up for the Kynetx Developer program go to www.kynetx.com.

Demonstration of the Family Link app can be found at http://richardkmiller.com/860.

About FamilyLink

FamilyLink provides the platform for the family social experience. Family members can create family-generated content, preserve interactions, add historical content and communicate across Facebook, e-mail, chat and the Web. FamilyLink is a top 100 Web site and has more than 60 million users, 20 million monthly active users and more than 1 million daily active users. FamilyLink has been the top family application on Facebook since 2007. FamilyLink also leverages its content relationships to provide valuable historical family content. Families can search more than 1.2 billion names to find, tag and integrate ancestors. To learn more about FamilyLink go to www.familylink.com.

About Kynetx

Founded in 2007, Kynetx is a private company that has developed a proprietary rules-based development platform that is the first infrastructure to support the “purpose-centric” web metaphor that is driving the next era of software services and Internet applications. Kynetx offers a developer program that gives programmers access to technology that helps them create cross-platform, context and user-aware apps that stretch across the web.

Contacts:

For Kynetx
Snapp Conner PR
Cheryl Snapp Conner, 801-994-9625
cheryl@snappconner.com

or

FamilyLink
Stephanie Rogers, Steph@familylink.com

The latest build (Build 391) of the Kynetx Rule Language (KRL) includes support for accessing Twitter data intrinsically within the language. Integrating interesting data with KRL is an important part of what makes the language so useful for building cross-site applications that mash-up data and user interactions. But what's really interesting about this release is that we're using OAuth to access the Twitter API and have built primitives into the language for dealing with the Twitter OAuth interaction to save developers from doing it.

Not only are we making it easy for developers to write apps that use Twitter, but this is also the first time that end users will see significantly different behavior from an app than their friend might. An app that uses the Twitter library will use my Twitter data for me and your Twitter data for you. Using OAuth, Kynetx apps can now be personalized.

Using Twitter data inside a KRL app generally involves two KRL patterns: authorize then use and initialize then populate

In the authorize then use pattern, a rule is put in place to check if the app is authorized to take a certain action and, if not, do what is necessary to complete the authorization. What makes this work is using the rule postlude to ensure that the rest of the rules (which presumably rely on the authorization) don't run. Here's an example from an app I wrote to demonstrate using the the new Twitter library:

rule auth is active {
  select using ".*" setting ()
  if(not twitter:authorized()) then
      twitter:authorize()
        with opacity=1.0 and
             sticky = true

  fired {
     last
  }
}

Notice that this rule only fires if the predicate twitter:authorized() is false. The action, twitter:authorize(), is what initiates the OAuth ceremony. The action will pop up a notification in the user's browser that looks like this:

The postlude of the rule (fired {...}) runs the last statement if the rule fires to ensure that nothing else happens. Of course, if the app is authorized, the rule doesn't fire, the OAuth ceremony is not initiated, the last is never executed, and the remaining rules in the ruleset are evaluated.

The initialize then populate pattern is important any time you're working with complex data. With complex data, you will frequently need to do something for each component of an array. That's what the foreach statement does as part of the rule selector: executes a rule once for each member of an array.

The problem is that if we use a foreach to loop over the tweets we get back and use notify to place them on the page, we'll end up with one notification box for each tweet. Not very pretty.

A better solution is to use a rule to place the notification box (the initializer) and another rule to loop over the tweets and place them in the notification box (the populater).

Here's the initialization rule:

rule init_tweetdom is active {
  select using ".*" setting ()

  pre {
    init_div = <<
<div id="tweet_list">
</div>
>>
  }

  notify("Friends Tweets", init_div)
    with sticky=true and
         opacity = 1.0

This is a pretty simple rule that places an empty notification box on the page.

The real work is done by the populating rule:

rule populate_tweetdom is active {
  select using ".*" setting ()
    foreach tweets setting (tweet)
      pre {
        text = tweet.pick("$..text");
        div = "<div style='background-color:#666;margin:2px'>" +
              text +
              "</div>";
      }
      append("#tweet_list", div)
}

This rule loops over the tweets, grabs data out of them using pick, and appends the result to the div in the notification box.

The tweets variable was set in the global block:

tweets =
  twitter:authorized() => twitter:friends_timeline({"count": 8})
                        | [];

After you've gone through the OAuth ceremony at Twitter, wherever you run this app, you will see a box like this that contains the last eight tweets from your friends timeline on Twitter. Here's the results for me:

Of course, if you run this app, either by card or bookmarket, you'll see the results from your friends timeline.

Craig Burton has created a nice tutorial about how all this works. There's some important data in the tutorial about how to get the keys from Twitter for your application. The library is also well documented and the source code for the ruleset is available.

The ability to personalize apps by appealing to personal data elsewhere on the Web is a huge step forward for KRL. Look for other APIs to be embedded in KRL in the near term and, eventually, more general support for OAuth so that developers can use any OAuth protected data source.