Before I start blogging here at Webcrossing Rocks, I thought it would be appropriate to say a little about myself, perhaps to give some credibility to the information that I will be relaying.
You can read some details on my profile, but the history at WebCrossing is a bit more complicated. I started at Lundeen and Associates (L&A) back in 1993, before the WebCrossing product was even a pipe dream. We were working on a cross-platform word processing/drawing type application which would have competed with Microsoft Word in many different ways. My job was to convert everything to work on a Windows platform, which included the database, windows, drawing, mouse functions, windows events, etc. which was all written in the C language.
Even though the Macintosh platform was the where most of the development happened, (and my preferred platform of choice) my task was quite daunting and took a couple of years to get right since I was the only Windows developer on staff.
During this time, funding became difficult and L&A took some outside contracts to keep the cash flowing so we could finish our product. One of these contracts was for a web community called "The Well" based in San Francisco. They wanted a cross platform "browser" which could act like an off-line reader for their massive bulletin board system and community that they had developed over the years.
We were able to modify our existing code base to produce just such a system and added several underlying technologies like Telnet and a TCP/IP system that would work over simple dial-up modem to modem or through the VERY new Internet system that was becoming public and popular at the time.
I worked on many of those underlying technologies as well as moving these to the Windows platform. We added our own scripting language system so that we could create the many changes that the client kept adding to the system. This was called "Author" and is the basis for WCTL that is still used today.
Weeks before we were to deliver the final product for "The Well" to roll out to the public, the owner of The Well decided to scrap the entire project, which had grown to quite a good system at that time.
This was a devastating blow to our small company, but we decided to take lemons and make lemonade. Michael Krieg, over the course of just a few weeks, was able to convert our "Author" system into a very simple bulletin board/forum/community system which we named "WebCrossing" and began selling in 1995.
It was a slow start, but we became quickly well known in the relatively small field of internet companies up until the Internet bubble burst in 2000 / 2001 where we then had to downsize significantly and enter a hibernation mode.
The product continued to be developed quite heavily according to massive customer input. We were constantly changing the software to meet new technology requirements that customers asked for. It has since become what we refer to as "The Swiss Army Knife of Web Development Technologies".
It has everything you need to develop an entire website - scripting language, dynamic Object Oriented Database, SMTP, POP3, NNTP, RSS, massive scalability through source/mirror clients. You name it - WebCrossing can do it.
It was an amazing time to work for the Internet industry and a great learning experience.
I look forward to sharing some of my insights, development secrets, coding techniques, and tricks of the trade in implementing a great site through the software.
We all welcome your comments as we begin this blogging collaboration.
Dave Jones
dave@lockersoft.com
http://www.youtube.com/lockersoft
Showing posts with label history. Show all posts
Showing posts with label history. Show all posts
WCTL and SSJS duke it out [Part 3]
OK, here's where it gets fun. Part 1 was about WCTL (Webcrossing Template Language) and Part 2 was about Webcrossing's newer, more powerful scripting language, SSJS (server-side JavaScript). Now they'll both put on their boxing gloves and show us their stuff.
| WCTL Webcrossing Template Language | SSJS Server-side JavaScript | |
|---|---|---|
| tight integration with OODB | yes | yes |
| easy for beginners | yes | no |
| good for experienced programmers | if you can get used to its limitations | definitely |
| tag-based | yes | no, every string going to the response buffer must be quoted (with one exception I will write about later in a full post) |
| use with client-side JS | easy-peasy | can be a bit of a hair-puller |
| case sensitivity | no | yes |
| number crunching ability | limited, integers only | full suite of JavaScript Math methods |
| execution speed | very fast | fast |
| use directly in Control Panel HTML textareas | yes | no |
| error handling | graceful, but little information | not always graceful, but great stack traces |
| out-of-box scripts | most are WCTL | a few are SSJS |
| object-oriented | pseudo, not really | yes |
| has arrays | no | yes, plus StoredArray() objects stored in DB |
| function parameters | no | yes |
| variable scope | very broad, across entire execution request | normal JavaScript variable scope |
| have multiple database location objects open at once | no, just current location | yes |
| have multiple user objects open at once | just user and author | yes |
| create new object types | sort of | yes |
| bottom line | blazingly fast, good for beginners, a little quirky | powerful, not so forgiving, just a trifle slower than WCTL |
SSJS: powerful and full-featured, not so forgiving [Part 2]
Webcrossing's second scripting language is server-side JavaScript (SSJS), sometimes referred to Webcrossing JavaScript (WCJS). What Web Crossing did along around version 3 was add support for the Mozilla Spidermonkey implementation of JavaScript.
JavaScript isn't usually thought of as a server-side language, but it's really quite rich and powerful on its own, and coupled with the OODB, you can do some really cool things. Since it's tightly tied to the object-oriented database (OODB), it's trivial to set properties on built-in forum objects.
Like WCTL, SSJS starts with the concept of "location" as the forum object at which the script is being run. From there, you can look up any other objects you want to work with. Any properties you set are automagically just saved in the database.
var someMessage = Stored.lookup( uniqueId );
someMessage.lastEditor = somebody;
But, unlike WCTL, you aren't stuck with a single current location. You can have as many Node objects available as you like:
var theFirstFolder = Node.lookup( uniqueId );
var theSecondFolder = Node.lookup( uniqueId );
var theThirdFolder = Node.lookup( uniqueId );
From there, you can do whatever you like with the first, second, and third folder objects you have open.
Same with users - no user/author dance like with WCTL.
var someUser = User.open( uniqueId );
var someOtherUser = User.lookup( name );
You can also create your own new object types based on the built-in primitive forum objects, prototype them as you see fit, and store them in the database.
As you can see, SSJS is really just plain old JavaScript, but there are some special methods added just for use within Webcrossing, like the $( someproperty ) hierarchical property-fetcher, date formatting methods, and more.
But SSJS might not be the best for beginners without any programming experience: as you would expect from a "real" programming language which is CaSe sensitive, has arrays and more than one variable type, and has functions with parameters, there is more than a small learning curve.
If you don't program defensively, it tends to throw up errors all over the page, but on the bright side, you get a really nice helpful stack trace for each error. Every bit of HTML going to the page needs to be quoted, which can eat up some time, and getting complex client-side JavaScript quoted and escaped just right in server-side JavaScript can be a bit of a nightmare sometimes.
Some of us swear by SSJS, some of us swear at SSJS, and all of us use it at least part or most of the time. When you need the power and flexibility of a real programming language, want to create and prototype your own objects, have to do something with multiple locations or users at once, or need to do some serious number crunching, SSJS is for you.
We covered the Webcrossing Template Language (WCTL) in Part 1, and Part 3 will summarize what the two languages are each best and worst at.
JavaScript isn't usually thought of as a server-side language, but it's really quite rich and powerful on its own, and coupled with the OODB, you can do some really cool things. Since it's tightly tied to the object-oriented database (OODB), it's trivial to set properties on built-in forum objects.
Like WCTL, SSJS starts with the concept of "location" as the forum object at which the script is being run. From there, you can look up any other objects you want to work with. Any properties you set are automagically just saved in the database.
var someMessage = Stored.lookup( uniqueId );
someMessage.lastEditor = somebody;
But, unlike WCTL, you aren't stuck with a single current location. You can have as many Node objects available as you like:
var theFirstFolder = Node.lookup( uniqueId );
var theSecondFolder = Node.lookup( uniqueId );
var theThirdFolder = Node.lookup( uniqueId );
From there, you can do whatever you like with the first, second, and third folder objects you have open.
Same with users - no user/author dance like with WCTL.
var someUser = User.open( uniqueId );
var someOtherUser = User.lookup( name );
You can also create your own new object types based on the built-in primitive forum objects, prototype them as you see fit, and store them in the database.
As you can see, SSJS is really just plain old JavaScript, but there are some special methods added just for use within Webcrossing, like the $( someproperty ) hierarchical property-fetcher, date formatting methods, and more.
But SSJS might not be the best for beginners without any programming experience: as you would expect from a "real" programming language which is CaSe sensitive, has arrays and more than one variable type, and has functions with parameters, there is more than a small learning curve.
If you don't program defensively, it tends to throw up errors all over the page, but on the bright side, you get a really nice helpful stack trace for each error. Every bit of HTML going to the page needs to be quoted, which can eat up some time, and getting complex client-side JavaScript quoted and escaped just right in server-side JavaScript can be a bit of a nightmare sometimes.
Some of us swear by SSJS, some of us swear at SSJS, and all of us use it at least part or most of the time. When you need the power and flexibility of a real programming language, want to create and prototype your own objects, have to do something with multiple locations or users at once, or need to do some serious number crunching, SSJS is for you.
We covered the Webcrossing Template Language (WCTL) in Part 1, and Part 3 will summarize what the two languages are each best and worst at.
WCTL: fast, great for UI, but a bit quirky [Part 1]
Webcrossing's original scripting language is a proprietary, built-in language called WebCrossing Template Language, or WCTL. Some years later, the Mozilla Spidermonkey JavaScript engine was grafted onto Webcrossing to act as a second server-side scripting language. We'll cover that in more detail in Part 2 of this series.
But first, WCTL. WCTL is currently officially "deprecated," so as not to scare off new developers, but it is still supported, and it has a number of useful qualities. In other words, you don't have to learn vast amounts of WCTL if you don't want to, but if you happen to pick it up, it can be quite handy.
WCTL is a tag-based language, and everything not inside WCTL tags is HTML output to the page. Server-side JavaScript (SSJS) is, of course, just the opposite. WCTL tags are delimited by %%'s, for example:
Hello, %% userName %%, welcome back!
Because it's not necessary to quote everything sent to the page, WCTL is much faster for front-end developers writing user interface. Besides just being faster to develop, WCTL runs a trifle faster than SSJS. WCTL can be used directly in Control Panel HTML textareas (SSJS can't). WCTL at its simplest is quite accessible for the amateur site owner who wants to add just a bit of dynamic content here and there, like the simple example above. But WCTL can be quite powerful, as demonstrated by the fact that most of the out-of-the-box scripts are written in WCTL. And it's CaSe INsensitive and is very forgiving of errors, unlike SSJS, which tends to barf all over the page if you aren't careful.
But WCTL is limited in some ways, and is admittedly a bit quirky. It is not really object-oriented, has only one data type (strings, although integer math can be done), has no arrays, and you can't use parameters with functions ("macros") you create yourself (although variable scope is very broad, so in reality that's more a nuisance than a real problem).
Webcrossing has the concept of "location" (in the forum hierarchy), which refers initially to the location at which a script is being executed. In WCTL, a sort of pseudo object-oriented dot notation - %% path.someproperty %% - makes it possible to reference stored properties of the current location. To reference the values at some location other than the initial one, you can %% setPath( uniqueID ) %% to the unique ID hex number of the forum object you want to reference so that %% location %% then refers to the new location, and then %% path.someproperty %% will refer to the new location's property.
You can do the same thing with users. %% user %% refers to the currently-viewing-user, and %% author %% can refer to either the actual content author of the current location, or some arbitrary other user whose properties you are interested in. For example, %% user.userEmail %%. Or %% author.userEmail %%. To examine that arbitrary user (author) you do: %% setAuthor( userId ) %%. From there, use %% author.someproperty %%. But, if you do that - Danger, Will Robinson! - you lose access to properties of the current location and will have to %% setPath() %% to regain access. (Remember, I did say it was a little quirky.)
You can mix and match SSJS and WCTL, although there is a small performance hit for doing so. So you could write your user interface in WCTL for speed, error-forgiveness, and to save time; and call SSJS functions to provide the complicated programming that is more convoluted to do in WCTL. In fact, that's exactly what some of us do.
We'll cover the Webcrossing implementation of SSJS in Part 2, and then Part 3 will summarize what the two languages are each best and worst at.
But first, WCTL. WCTL is currently officially "deprecated," so as not to scare off new developers, but it is still supported, and it has a number of useful qualities. In other words, you don't have to learn vast amounts of WCTL if you don't want to, but if you happen to pick it up, it can be quite handy.
WCTL is a tag-based language, and everything not inside WCTL tags is HTML output to the page. Server-side JavaScript (SSJS) is, of course, just the opposite. WCTL tags are delimited by %%'s, for example:
Hello, %% userName %%, welcome back!
Because it's not necessary to quote everything sent to the page, WCTL is much faster for front-end developers writing user interface. Besides just being faster to develop, WCTL runs a trifle faster than SSJS. WCTL can be used directly in Control Panel HTML textareas (SSJS can't). WCTL at its simplest is quite accessible for the amateur site owner who wants to add just a bit of dynamic content here and there, like the simple example above. But WCTL can be quite powerful, as demonstrated by the fact that most of the out-of-the-box scripts are written in WCTL. And it's CaSe INsensitive and is very forgiving of errors, unlike SSJS, which tends to barf all over the page if you aren't careful.
But WCTL is limited in some ways, and is admittedly a bit quirky. It is not really object-oriented, has only one data type (strings, although integer math can be done), has no arrays, and you can't use parameters with functions ("macros") you create yourself (although variable scope is very broad, so in reality that's more a nuisance than a real problem).
Webcrossing has the concept of "location" (in the forum hierarchy), which refers initially to the location at which a script is being executed. In WCTL, a sort of pseudo object-oriented dot notation - %% path.someproperty %% - makes it possible to reference stored properties of the current location. To reference the values at some location other than the initial one, you can %% setPath( uniqueID ) %% to the unique ID hex number of the forum object you want to reference so that %% location %% then refers to the new location, and then %% path.someproperty %% will refer to the new location's property.
You can do the same thing with users. %% user %% refers to the currently-viewing-user, and %% author %% can refer to either the actual content author of the current location, or some arbitrary other user whose properties you are interested in. For example, %% user.userEmail %%. Or %% author.userEmail %%. To examine that arbitrary user (author) you do: %% setAuthor( userId ) %%. From there, use %% author.someproperty %%. But, if you do that - Danger, Will Robinson! - you lose access to properties of the current location and will have to %% setPath() %% to regain access. (Remember, I did say it was a little quirky.)
You can mix and match SSJS and WCTL, although there is a small performance hit for doing so. So you could write your user interface in WCTL for speed, error-forgiveness, and to save time; and call SSJS functions to provide the complicated programming that is more convoluted to do in WCTL. In fact, that's exactly what some of us do.
We'll cover the Webcrossing implementation of SSJS in Part 2, and then Part 3 will summarize what the two languages are each best and worst at.
WebX != WebEx
Before we get too far here, let's be clear about who we are and what product we're talking about.
One thing that irks me to no end is people confusing Webcrossing (often abbreviated WebX, like in our URL even) with Cisco's WebEx product. I discovered this tweet just a few weeks ago: "Bayspire, current owners of Web Crossing (née WebEx)..."
AGH!
But I have to admit there are, unfortunately, reasons people get confused:
One thing that irks me to no end is people confusing Webcrossing (often abbreviated WebX, like in our URL even) with Cisco's WebEx product. I discovered this tweet just a few weeks ago: "Bayspire, current owners of Web Crossing (née WebEx)..."
AGH!
But I have to admit there are, unfortunately, reasons people get confused:
- Cisco owns the domain WebX.com. So some unwary surfer looking for Webcrossing.com would end up at WebX.com and the wrong product. Since they had lawyers with bigger biceps than Webcrossing's, it stayed that way. (Right now a surfer looking for Webcrossing.com lands at Bayspire.com, but I digress...)
- The old Webcrossing logo - which I believe predated the existence of WebEx - didn't help, as it used a swoopy red X between the words "Web Crossing."
[Trivia fact: A large version of that logo was actually animated on the Webcrossing website splash page way back when people actually had splash pages] - Before the advent of actual WebEx-style web conferencing, the word "conferencing" used to refer to a large-scale web forum like, say, Salon or Electric Minds (archive) or the WELL. Along comes WebEx, offering - you guessed it - web conferencing.
Webcrossing: the best [fill in product definition here] you never heard of
Webcrossing was a pioneer; it was Web 2.0 when there barely was a web.
Back in 1995, Webcrossing was born as a product from a software group named Lundeen and Associates, headed by Tim Lundeen, a brilliant developer with a track record of success with mass market software. Tim was the lead developer for Apple's port of Microsoft Works.
Since the beginning Webcrossing has been about user-generated content and "the participatory web," providing industrial strength forum software to big-name companies. It has been lauded for its extreme customizability and flexibility, and its ability to support large sites. (A single discussion on CNN once generated a quarter million posts during a US Presidential race and Webcrossing didn't blink.)
Since then, Webcrossing has grown and evolved into forum software, content management, social networking, and more. It's a multi-protocol server (http, smtp, pop, imap, nntp, ftp) tightly integrated with an object-oriented NoSQL database. There are dozens of plugins and a web application development platform with built in content and user objects that can save tons of development time. In reality, Webcrossing can actually be just about anything you can dream up.
Which explains why you may never have heard of it. It's a difficult product to market, to categorize, to explain in an elevator pitch.
And that's where we come in. Some of us are employees of Bayspire, the current exclusive licensee for Webcrossing support, service, and sales. Some of us are independent developers with a lot of Webcrossing experience. All of us share an unbridled enthusiasm for the Webcrossing platform, and we are are dying to tell you just what we think is so cool about it.
So let's get started, and we'll give you the grand tour of Webcrossing. Soon you'll know why WebX Rox!
Back in 1995, Webcrossing was born as a product from a software group named Lundeen and Associates, headed by Tim Lundeen, a brilliant developer with a track record of success with mass market software. Tim was the lead developer for Apple's port of Microsoft Works.
Since the beginning Webcrossing has been about user-generated content and "the participatory web," providing industrial strength forum software to big-name companies. It has been lauded for its extreme customizability and flexibility, and its ability to support large sites. (A single discussion on CNN once generated a quarter million posts during a US Presidential race and Webcrossing didn't blink.)
Since then, Webcrossing has grown and evolved into forum software, content management, social networking, and more. It's a multi-protocol server (http, smtp, pop, imap, nntp, ftp) tightly integrated with an object-oriented NoSQL database. There are dozens of plugins and a web application development platform with built in content and user objects that can save tons of development time. In reality, Webcrossing can actually be just about anything you can dream up.
Which explains why you may never have heard of it. It's a difficult product to market, to categorize, to explain in an elevator pitch.
And that's where we come in. Some of us are employees of Bayspire, the current exclusive licensee for Webcrossing support, service, and sales. Some of us are independent developers with a lot of Webcrossing experience. All of us share an unbridled enthusiasm for the Webcrossing platform, and we are are dying to tell you just what we think is so cool about it.
So let's get started, and we'll give you the grand tour of Webcrossing. Soon you'll know why WebX Rox!
Subscribe to:
Posts (Atom)