Monthly Archives: November 2013

Web.Next

Dave Winer: “But all that has changed with the ability to access cloud storage from apps written in JavaScript that run in the browser. Software that used to require a central server, and was easy to attack, and had to scale for all sizes of use-cases, now can run in the browser, with little if any loss of power.”

Dave is excited he can host a JavaScript on a server and pull it to the browser to execute because it affords him the ability to do simple applications without the need of web services. I can understand his excitement. It’s less expensive than running a GIGANTOR set of servers to host your services and answer requests thrown at them from the client. Point taken. It’s a step in the right direction, but I still think services are necessary for all but the smallest of apps because browsers still don’t make great hosts for applications.

Bringing in the Harvest
I think designing services first is the more appropriate thing to do. Don’t think about the UI first. UI’s are a dime a dozen and should be lowest common denominator (browser), up to native, high performance, best of breed (platform specific; iOS, Android, etc.) Because mobile is so important today you can’t leave that out of any discussion about web based services. Most web apps I’ve run on my phone are pretty horrible performance wise, but I can run them. If I have a choice to get a native mobile client I always opt for it because of that.

Dave accused me of calling him stupid.

Far from it, Dave. I know you’re not stupid, I just have a different idea than you, that’s all. A differing of opinion, and that’s ok. I think you’ll be very happy with your new model and out of that we’ll see some great browser apps.

I’ve talked about it before. I’d like to see the browser evolve way beyond what it is today if this is the new “OS” for the web based world. It must if we expect to create beautiful, highly usable, fully functional applications like we did on the desktop before the invention of the browser.

When the browser can evolve to a faceless shell that is language agnostic and allows us to control it like a native application controls the desktop environment, man, then we’ll have something special, until that time it will provide the lowest common denominator gateway to the web.

Web Next

Can you imagine the explosion of high quality code and components that would flow out of a world where we’re not limited to the confines of the browser and JavaScript? It would be industry changing.

I’d love to see the browser community embrace the idea of a full CLI implementation and create a way to hit and endpoint URL that pulls a fully built application to the desktop that’s hosted by an “invisible” browser. [UPDATE: This part, about pulling a full app plays nicely with what Dave is talking about.] The browser should serve as the new OS giving the developer full access to a virtualized machine.

We’ll get there, some day.

Pelco SDK 3.3.1 – Collecting Devices C++ Sample

Disclosure

By day I’m the Development Lead for a small group of folks responsible for the Pelco SDK. This post is not an official Pelco article, just something I wanted to share.

Background

Last August I rejoined Pelco to help design a new object oriented version of the SDK and that’s what we’ve been doing for the last year plus. We’ve released four revisions of the SDK over that time period and are working on our fifth.

Something I’ve wanted to share for a very long time is how simple it is to work with our new Object Model to collect devices and play video. We’ve simplified the entire process. The original version of the SDK evolved from need, as a lot of things do, but over time it becomes more and more difficult to maintain and enhance that code without breaking backward compatibility. In the new Object Model we’ve worked very hard to make it easy and give you the power you need to code new solutions and give us a platform to build on in the future.

I plan on sharing a sample application after a very brief overview of our Object Model. The application, called EnumDevices, is a C++ application. You can find it on GitHub. I’d be happy to create the same application in C#/.Net. If you’re interested get in touch, rob@crabapples.net.

Overview

The Object Model is pretty simple, here are a few objects, just to get us started. You can view the entire list on PDN(it’s a PDF file.)

  1. SystemCollection
  2. System
  3. DeviceCollection
  4. Device
  5. Camera
  6. Display
  7. Stream

Of those we’ll discuss System, DeviceCollection, and Device in the sample. There is some boilerplate code you’ll need to write, but we’ll skip that for now, so we can get on with the sample. Look at main() in the EnumDevices sample, the boilerplate happens prior to calling the EnumDevices function. Something to note. This sample uses version 3.3.1 of the SDK, which introduced an explicit Startup() and Shutdown() function, keep that in mind if you’re using version 3.0 through 3.3, these functions don’t exist in those releases.

EnumDevices C++ Sample

On to the sample code. If you haven’t grabbed the code yet, head over to GitHub and pull it down, I’ll wait.

Some things to note about the sample code. It’s only available for Visual Studio 2010. Our SDK only supports Visual Studio 2008 and Visual Studio 2010 for the time being. I have no idea how it will behave in Visual Studio 2012 or Visual Studio 2013.

Ok, on with the code. We’re going to focus on one function in the sample; EnumDevices. This little bit of code will add, or get, a System, get the DeviceCollection and enumerate it. As it does it will print out the Device Friendly Name. That’s it.

Here’s the code, we’ll break it down below.

static void EnumDevices()
{
        // Create or get an existing system
        PelcoSDK::System system("admin:admin@pelcosystem://[insert your ip and port here]?alias=Enum Devices Sample System");

        // Get the Device Collection from the system
        PelcoSDK::DeviceCollection devices(system.GetDeviceCollection());

        // Iterate over the DeviceCollection and print out the device friendly name.
        devices.Reset();
        while (devices.MoveNext())
        {
                PelcoSDK::Device device(devices.Current());
                printf("Device Friendly Name: %s\n", device.GetFriendlyName().c_str());
        }
}

PelcoSDK::System

Dissecting the code. I’m sure the first line of code, where we create the System, will have folks asking questions. When we were trying to decide our model for creation and access of Systems we wanted to make it as easy as possible and provide a great deal of power without forcing the user to jump through a lot of hoops. In the end it was decided we’d fashion it after a URI Scheme. Today most people know what a web address looks like.

Here’s the line of code in question:

PelcoSDK::System system("admin:admin@pelcosystem://1.2.3.4:80?alias=Alias");

The interesting portion of that line is "admin:admin@pelcosystem://1.2.3.4:80?alias=Alias". In our scheme “pelcosystem” represents the scheme name, we’ve put the username and password information to the left of the scheme, before the @. Following the :// is the host name, followed by the port, and a query string. We use the query string for arguments, in this example we’re assigning an alias name to the System so we can use that to look it up later, or display it in our user interface.

Something else to note about the use of the scheme in the sample. It serves to do the initial add of the System to the SystemCollection and works to look the System up later, without going to the SystemCollection. Our sample could have also added the System to the SystemCollection by using the Add method directly on the SystemCollection, but it’s not required. That said, the first time you run this code it will be a bit slower than subsequent runs. The first time through the System and all its devices will be added to a local device cache so the next time you startup will be much quicker.

PelcoSDK::DeviceCollection

The second line of code is pretty straight forward. After we’ve created, or retrieved, a System we’d like to get the DeviceCollection so we can do something interesting. Maybe we’d like to populate a tree control with a list of devices, or just dump out device information to a simple console application, like this sample.

PelcoSDK::DeviceCollection devices(system.GetDeviceCollection());

There’s not a lot to talk about here. We’re constructing a C++ object of type PelcoSDK::DeviceCollection using the results of a call to system.GetDeviceCollection(). Now we have a DeviceCollection Object we can enumerate.

All of the collection classes in the SDK implement an interface called IEnumerator, it’s a template class that exposes three methods; Current, MoveNext, and Reset. These methods make it really easy to iterate all collections in the SDK with a simple while loop.

devices.Reset();
while (devices.MoveNext())
{
	PelcoSDK::Device device(devices.Current());
    printf("Device Friendly Name: %s\n", device.GetFriendlyName().c_str());
}

After getting our collection it should be in a “reset” state, but the first line of code above shows how to reset the internal iterator back to the beginning of the collection. Notice the while loop checks the result of the devices.MoveNext(). The MoveNext method will move the iterator to the next item in the collection and returns a boolean value, true if it has a next device, false if it doesn’t. Once there are no longer devices in the collection we’ll break out of the loop.

If we do have a device in the collection you can retrieve it by asking the DeviceCollection for its Current() object. Since IEnumerator is a C++ template the type of object returned is a PelcoSDK::Device. You can read more about the Device Object on the Pelco Developer Network(PDN).

EOL

Hopefully this sheds a bit of light on the direction of the Pelco SDK. We’re off to a nice start, but we have a long way to go, and we’d love to hear back from developers and partners. Please, reach out. Let us know how we’re doing, where we need to improve, and share your stories.

Until next time, happy coding.