The last post discussed the "dancing bunnies" problem and offered a resolution by triggering an instinctive "danger" response from the user. While considering the problem, I started thinking: would this problem always exist? Is it a definitive feature of user-system interface, or is it a problem relating to the core of being "human"?

We, the people of Troy

The city of Troy was a secure system. They had strong walls, alert guards, and were well trained, until this appeared:

The Trojans clicked "Run" without even reading Laocoon and Cassandra's warning, and to this day, Trojan horses, bunnies and lolcats are wheeled through the walls. Maybe we should stop it. Stop building walls, that is.

We, the people of the Web

They promised me a network computer. They really did. A dumb terminal that I'll touch with my thumb and it will immediately access all my services from the web. Let's assume they will make good on that promise. Now, will it be more, or less secure? Obviously, it won't be as secure as a personal computer that is not connected to the web. Let's assume that every computer is connected to the web and assume that they are very well protected, except for security risks caused by the users themselves. That's a very lenient assumption, so let's be kind to the net terminal as well. We'll assume that data, kept remotely, is secure from attacks and can only be accessed by its rightful owner. We will also assume that all services currently enabled on the net terminal are non-malicious. That last assumption is not enough because we have to assume also that every service enabled is also safe from attacks, meaning that it is impossible to hack into the service itself or fake the service's certificates.

Now we are offered a new service called Trojan Horse. It's a cool service that shows a horse on wheels rolling on the task bar, ejecting dancing bunnies every now and then. How will this look like on the net terminal? Maybe something like this:

You may notice that I have a lot of control here. I could allow some application to use the screen (for a limited time), deny it the speakers if I'm at work or ask to run it anonymously. This will create a negotiation between the running program and the user, perhaps notifying it that the application cannot run without access to personal settings. Now that I do not have one central wall blocking access to my computer, I have little walls blocking access to each resource type. I can use these little walls to control programs even after they have been installed, for instance, if I am notified that the software is about to release Greek soldiers and take over my system (which I have not yet granted it permissions to do), I could deny it.

Better living through more protocols

The real beauty of this is that all the technology for cloud computing and authorized access to resources exists today, only not at the right place. Billing systems do it all the time: authenticating users, consuming resources, tracking usage. The Diameter protocol, for instance, can be used just as well when protecting system resources. Applications can authenticate themselves, consult local policy servers, request and consume resources. They can be tracked and permissions to abusive programs can be revoked.

Does this solve the "dancing bunnies" problem? Not immediately, but it does allow the system to monitor and locate abusive programs and then alert the user, so on the long run, they will be found and removed. This can also be done in current systems, but since it is not broken down into components that communicate with each other, it will require many resources just to keep track of everything - which might be worse than drunken Trojans. When it comes to controlling which programs are allowed what access to your resources and personal data, a network computer is safer than a desktop computer. If we consider that sometime in the future we'll carry our personal data on a mobile device and use such terminals just to access remote information or use cloud computing services, our personal data is likely to be much better managed than it is now.

Jeff Atwood of Coding Horror wrote some months back on the fake user interface, and its ability to trick innocent users into running malicious software. It was on my to-do list for a while, but now I noticed a link to another post from three years ago, discussing the "dancing bunnies" problem (aka the "dancing pigs" problem), as formulated by Larry Osterman:

It's a description of what happens when a user receives an email message that says "click here to see the dancing bunnies".

The user wants to see the dancing bunnies, so they click there. It doesn't matter how much you try to dissuade them, if they want to see the dancing bunnies, then by gum, they're going to see the dancing bunnies. It doesn't matter how many technical hurdles you put in their way, if they stop the user from seeing the dancing bunny, then they're going to go and see the dancing bunny.

Dance, Bunny! Dance!

The original discussion back then was as to the need for antivirus. Today we regularly use antivirus, adware removal, spyware detection, anti-phishing, spam filters, firewalls, server-side protection, permission management, homepage kidnapping prevention, internet zones and site certificates, and people still want to see the dancing bunnies! Only problem is, their PCs are so slow due to all the security software that they can't get it running.

Now, what if we were just walking down the street and someone said "Hey, bud, want to see some dancing bunnies?"

You'd probably run like hell, won't you? Look INSIDE the box? What are you, crazy or something? Every alarm system in your head will go off if someone just came towards you looking like that. The problem is, we don't see emails and web pages as shady little guys with gray trench coats and hats going "Hey, bud". We're too used to TV and books, and TV and books can't hurt you, can they?

Whom Can You Trust?

When I access my work mail from the web, I get a security warning about an expired certificate. That's OK; our IT goes "that's our warning". Just confirm it anyway. Internet Explorer warns me every time, while Firefox lets me set a permanent exception, so I'm using Firefox for mail access even though it looks a little strange. My OS warns me about running any file that's not local, and the first time I run a file I downloaded.

It really does beat the point, does it? On one side, there are all these friendly interfaces and authoritative messages, on the other side, tired warnings and checkboxes that say, "Always allow". Besides, we really do want to see the dancing bunnies.

I don't even believe in the "virtual sandbox OS" suggested by Jeff. How about this:

You'd confirm it in a second, because you trust the friendly sites, because you are used to the nice emails from friends sending you dancing bunnies. More dancing bunnies please.

Websites are Strangers in Dark Alleys

Until this realization is hammered deep into the user's mind, no security can be good enough. We must tap into the same inner protocols that intuitively make us realize danger is about. None of these friendly notifications will do. Here is my suggestion for a warning screen:

The picture will change randomly, of course. If you click on that without considering physical harm, well, bud, you have worse problems than viruses.

Maybe I'm being naïve. What do you think?

How's this?

What?

You don't see any difference?

Maybe it's your RSS feed. Come closer. Look around.

Still nothing?

We changed! A new theme! New widgets! New homepage! New "about" pages (and easier contact forms)!

We even moved to a new host and a new platform (and solved the annoying email notification for comments thing).

Nothing, huh? Sometimes I don't know why we bother. Well, actually, Tsahi did most of the bother, but we provided moral support. Let me know if there are spots he missed or anything that needs fixing so then we can rub his nose in it. You can also say how nice the new design is, but don't overdo it, he's ego's big enough as it is and we'd appreciate it if it didn't grow any further.

My last post was a bit poetic. The intention was to list the advantages of the void pointer, and to mention a few pitfalls associated with the usage of void pointers. In this post I will explain the same points, only in non-Zen-master-language. Using void pointers is perceived as half laziness and half foolishness, and the "serious" programmers will have none of it: they use templates, container classes and/or interfaces when appropriate. Some programmers prefer the other extreme: loose typing where every pointer is like a void pointer, and the end result is constant type checking. These latter types may also find the methods in this post interesting, although they are probably already using them.

The void pointer is like a general usage pointer, removing the need for container classes and templates, which are commonly used when creating generic data structures such as a list, hash, vector, stack, queue, etc. This same flexibility gives the void pointer its bad rep. Some prefer not to point at objects at all but to copy them instead, and some prefer a system where a reference counter is maintained between all containers. Both are redundant if void pointers are used with care, although a reference counter can be used with void pointers as well. I personally prefer cross pointing: the object should be able to reach any location where it is pointed to. If a hash or a list points at an object, the object should point back to the hash or the list. This makes removing the references when the object is deleted a little easier.

Care and Handling of a Void Pointer

I'm not saying that using the void pointer is easy. In many ways, it requires more care and planning than using templates. I am saying that it is more efficient, less memory consuming and a more flexible way of programming - when used correctly. When misused, void pointers can be cast incorrectly, accessed after the object being pointed to was deleted (any pointer can, but void pointers are move vulnerable since they do not know the object), or just cause confusion and waste time.

Dont's:

• Don't overuse void pointers. Sometimes templates are good, and sometimes the use is just too specific to try and make it general-purpose.
• Don't use them to pass instead of object handles. Object handles carry valuable information about the type of object passed.
• Don't use them for obfuscation. There are better ways, which are less confusing (see handles, above)
• Don't pass them between modules without knowing their meaning; this will always lead to confusion, especially when something is changed in either of the modules.
• Never use NULL as a valid value: NULL means "no-value", if you really have to pass zero as a value, reconsider the use of void pointers.

Do's:

• A pointer (not just a void pointer) should start out pointing at NULL, and be returned to pointing to NULL once the object is removed.
• Use one instance of a void pointer to point at a single type of object. For instance, if you have a void-pointer-list object, use it for one type of object, create another instance of it for another type and document each instance well. This may seem risky, but the footprint overhead for using templates makes it worthwhile.
• When passing void pointers for usage (i.e. not for storage or as user context), always provide an enumeration serving as a guide to the contents of the void pointer. The receiver will recast the void pointer according to the guide. This will save a lot of trouble should future changes require passing something else.

The Best Advice

Keep your eyes open! The void pointer will require the programmer to know what he's doing, pay attention to valid and invalid pointers and to where everything is. Before deleting any object that's pointed to, the object must go over all the places pointing to it and remove them. Whenever using a void pointer to point at anything, go over the checklist:

1. Does the object point back?
2. Does the object know when it is pointed to and when it is not?
3. Does the object remove the pointer to it when it is deleted?

If the answer to any of these is "no", you'll end up pointing at a deleted object, which is crushing. One thing's for sure: it will keep you alert.

I am the Zen pointer. I point at the Void. I make no separation between the NULL and the object. I am the ultimate container, containing everything and nothing. I see no difference between one type and another, between an object and an integer. I point at the world, yet I know I am part of the world, as I may be pointed to by another Void pointer. I may become all, and all may become me. I am the Void pointer. Hear me roar.

I am the Void pointer. Some may fear me. It is their own Void that they fear, their own lack of knowledge. The ones with insight wield me with confidence. The ones who are lacking dangle me and throw me as they spread errors and exceptions all around them. Seek out the true path of the Void pointer; do not hide behind false containers and interfaces, do not raise walls of templates to ward me. I am the Void pointer. Meet me eye to eye.

The True Path

The Tao of the Void pointer is not an easy one. It is full of doubt and uncertainty. Yet the ones with the insight reap its rewards. Eat from the fruit that is plentiful along its road: the fruit of memory, the fruit of agility and the fruit of efficiency. Remember, you who seek the Path of the Void: you are the one who walks. Do not be led by the path or it will lead you to uncharted realms. Always start out pointing at the NULL. Always end up pointing at the NULL. While on the path, always try to point out the same objects: point at a tree to remember the tree, do not point then at a flower lest you think the flower a tree. If you made a chain of Void pointers, use one instance of it for the flowers and another instance of it for the trees. The chain is the same, and its footprint is one, yet I can bind in it any type of object, just be sure to bind one type at a time. I am the Void pointer. Heed my warnings.

You may need a guide when you walk The Path of Void. The Void is a cloak, a veil; it may hide anything in its folds. Such a cloak is very powerful: When a passage is made for an object, it will fit only it and none other, but when a passage is made for a Void pointer, anything can pass through it, covered in the cloak of the Void. When it reaches the other side, it must be called by its name to unravel the shadows of Void. The wise make two paths, one for the Void and one for its guide, so the Void can be called it by its name and the veil removed to reveal the true object behind it. The many are united by the Void, yet still they have many names. I am the Void pointer. Forget my name.

The Master of the Void

The master of the Void must keep his eyes open: the Void knows nothing and sees nothing; all things are one to him. It knows not when memory becomes figment. The master must know all the Void pointers pointing at his memories, and he must cast them away before the memory is forgotten. If he will not, false memories will be dredged up from the Void, crashing down on his head. The master of the Void fears not the Void, for it is his friend and ally. I am the Void pointer. I am your friend.

GUI, the final frontier. All the bits flowing through the network, all the lines of code running through the processor, all the DSPs and the codecs, all the man-years, and what the user will see is just a GUI. And they never let programmers touch the GUI, now do they? That's the designer's job, and while a few designers dabble in programming to some degree, user interfaces designed by full-time programmers tend to stand out for being, how shall I put it, "practical".

Practical UI vs. Pretty UI

So programmers stick to their console windows, their favorite GUI toolkit language, and they realize that once a designer comes along, he will wave his magic stick and create the magical GUI experience. The one that the programmers will slam because it's not practical enough. This is, of course, because they give bad requirements (if at all).

Where Interface and Protocol Meet

Many efforts have been made to combine protocols with interfaces. In the world of SaaS and cloud computing, this makes a lot of sense. I'll focus, therefore, on GUI accessed through the network. The application should be accessible from a remote client, but we want buttons to be responsive and the display windows to refresh in real time. We want to use it from different operating systems and hardware, but we don't want to invest the development effort. A very good FAQ sums it up nicely (including comparisons to AJAX, HTML, Flash, Java, etc.) and links to many of the solutions available today, like RIA, Adobe AIR, WHATWG, XUP. There are more, I'm sure. One thing in common with them all is that they are doing it the wrong way.

The main idea of most remote GUI protocols, nay, with most multi-platform GUI toolkits, is the assumption that all users must see the same GUI on all platforms. That may have been true when nearly all users were teen to adult, used a PC, had about the same screen resolution, used the same input devices and used a limited set of applications. Today we have handhelds and home entertainment centers; we have multi-touch screens and wiimotes, we have nine year olds and ninety year olds using the same applications, and they cannot possibly have the same needs. A good trend today is to use HTML and have different CSS files for different types of devices. This is done today specifically for mobile devices (and iPhone in particular), with the tiny problem of having to redo the design part of the page all over again for each device out there.

I'm not even talking about the edge cases: I bought a laptop a few years back with an insane screen resolution, especially for its screen size. Now, LCD screens only look good in their native resolution, and I hate squinting, so I just set the DPI to a higher number so that windows will increase the font and icon sizes appropriately. Do you realize how few application developers consider this possibility? I have non-resizable windows with the text just sliding off the window's edge. I have buttons that are rendered outside their window. I swear. A lot.

 
Messed up mouse properties window (not resizable)

What I'd like to See

I want a GUI protocol that will not tell the client how to render the GUI, but instead will tell it what resources the GUI needs. Some ideas:

• If it contains a menu, tell it what's on the menu.
• It could indicate the application needs some message box resource, a video output resource or a rendering window.
• It could detail buttons with optional text and an icon (perhaps a vector representation of it, so it could be easily resized), entry boxes, check buttons, etc.
• The elements could be listed according to association, so that elements relating to the same issues will be grouped together.
• Furthermore, such elements could be prioritized: elements marked as vital will have to be rendered, and then the rest can be rendered according to some importance and usefulness factors.
• Perhaps a "skill" factor can also be added to hide or expose advanced options.

What will be left for the client is the actual appearance of the GUI, which can be classic or 3D, space-economic or greedy, hardwood or liquid-metal. As a bonus, if all the applications running use the GUI protocol, the user's desktop (or TV, or mobile device, or whatever) will look stunning. It will be like a theme, only more than skin deep. It will also balance the load differently between GUI designers and interface creators: the protocol will become a very detailed requirements document, detailing every option by importance and accessibility, and it would be the job of the client designers to take these requirements and provide a suitable GUI. A suitable GUI, in this context, is a GUI that fits the device's capabilities and user's preferences: simple and compact for handheld devices, large for hi-res systems. Mobile device manufacturers can provide a client that would render web applications as if they were part of the phone, while HTCs can let the user choose a theme and theme variants for each application. A utopia? Maybe, but as the user variance increases, so would the necessity for such a solution.

[This is the first guest post in my little blog, from your good friend at RADVISION customer support: Eran Zwilling, our head of Customer Support.
Did you ever wonder "Am I doing it wrong? Could I say a magic word (besides ?please') to get that extra mile?" The answer is finally here: 'No', but also 'Yes'. No, because the Customer Support reps are already working as hard as they can for you. Yes, because the following tips and insights will save you and them a lot of time. Read on for your CS 101.]

Do you really read manuals before you start using your brand new TV set? Have you ever read the "How to use your new mobile phone" or "How to set up your new Word Documents / PowerPoint" documents? Well, if your answer to any of the above is a "Yes", then way to go! Because I actually, almost never do so.

In fact, most of us engineers don't read manuals. We try to save time by jumping straight into the deep water "knowing we'll be fine". When you buy a good product, you already invested your time, efforts and money to choose the most cost-effective one, and you expect things to be intuitive, simple and fast. If I wanted to read a book, I can find one on Amazon. Manuals are simply not for me. I just don't have the time for them.

Still, if you just purchased a Mercedes-Benz car, you expect everything to be simple and intuitive, that the car will drive effortlessly and take you where you want to go with the least hassle and the most comfort. Why shouldn't you? It's a Mercedes, isn't it?

However, even a Mercedes-Benz sometimes needs a mechanic. Luckily, the best mechanic is a web page away - that's the motto of RADVISION Customer Support center.

Pleased to meet you: RADVISION Customer Support Center

RADVISION Customer Support Center is a group of the most expert VoIP engineers in the industry, with many years of experience in R&D, design, QA and testing of hundreds of products being developed every day around the globe. We are working in various time zones and in every continent in order to serve every customer in the fastest and most professional way.

We must have varied skills and orientations in our team, in order to take care of customers with different needs and different cultures. Customers have different levels of understanding in networking and protocols - some are using a specific network protocol for the first time, while others are replacing their ‘in-house' developed protocols with ours, and know enough to be able to work with RADVISION. Customers have different expectations from our products - some expect them to do the bare minimum and to stay out of the application's logic, while others expect them to handle everything. Finally, customers expect different things from customer support - some want quick tips and fixes to get them going, while others need thorough explanations and in-depth analysis of the product's inner workings.

Our main activities

RADVISION Customer Support Center is in direct contact with our customers, giving an extra personal touch to our professional business orientation. The Center's main activities are:

1. First steps: Helping customers understand their needs and helping them make the right choice of the best VoIP solution for their needs.
2. Point of Contact: Being the first address for all technical, presale and post sale matters.
3. Training: Building and tailoring training programs that help customers simply get to work, without diving deep into hundreds of manual pages. We understand what you are doing and will develop a training suite best for you.
4. Help your (development) dreams come true: Answering your questions and trying to solve any issue that may arise, such as:
   1. How to use RADVISION Toolkits
   2. Architectural consultancy
   3. Workarounds, bugs, enhancements
   4. Additional features, both standard and non-standard ones
   5. Testing assistance
5. 24/7 online self service: By maintaining the online Customer Support Portal eService, we make sure that you'll be able to find anything you need 24/7! Using the eservice (http://support.radvision.com/eservice/ ), you can submit any support request, download new updates and upgrades, and get all the documentation that you need. We try to make your life even easier by implementing the following great features in the eService:
   • Application Notes: Publication of direct and focused application notes, quick start guides and other useful developers' stuff.
   • Knowledge Base: Useful knowledge base and FAQs, based on other customer's notes, feedbacks and our own experience.
   • Download Links: Access to new updates, upgrades and essential documentation.
   • Know what is HOT: Be the first to know what's being cooked in RADVISION's labs, simply by registering (here) to get newsletters and updates.

Are we getting supportive? OK, bad pun.

This is your cue: tell us how we're doing. If you used our CS, we'd love to hear it.

I recently read a post written by a (cranky) Product Manager (PM), describing different programmers from a PM's view. The whole post is decretory and self-centered (as usual for cranky PMs), evaluating programmers not as people but as clichés, and overall is quite insulting. The easy thing for me would have been to write an equally decretory view of PMs: the MBA-PM, the "I was a developer guru" PM, the "I got here because I was a bad developer" PM and the "I got here because I was a bad developer but I THINK I was a developer guru" PM.

Instead, I decided to take the high road:

I got together with some of my peers to discuss the characteristics of a PM. We're a technical bunch, so it took us just 30 seconds to reach a conclusion: PMs have but two configuration variables from which all interactions with them (APIs?) derive:

1. Has technical skills = (True/False)
2. Knows what he wants = (True/False)

All the rest of a PM's character is just volume control, circumstances, personal compatibility and personal hygiene. If you take these away, there are just four combinations of PMs which derive from the above two Booleans.

[For PMs who bump into this post by mistake, here's a graphical representation:

 
Figure 1: Code Of Contact's Configuration Table for a PM

Got it? Good. Now I can proceed.]

 

Super Star (Tech = True; Knows = True)

If that's your PM, you're a lucky dog. He will not only know what needs to be done, but he will know what can and cannot be done and in what costs. Not only will product demands be technical in nature and broken down to modules, they will be realistic and leave room for last minute changes. He will watch your back from hidden pitfalls; he will provide that crucial correction to your design; he will even offer to code that tricky little feature. The only problem is that you can't bullsxxx him. It's not a biggie; he knows what "black-ops time"* means and will gladly put some on your Gantt chart. You may feel a little obsolete and overshadowed, but that's just you. He's great; trust me.

Quote: "I thought of a cool new feature for the product, so I coded it last night."

 

Exclamation Mark (Tech = False; Knows = True)

It may be tiring to explain repeatedly that effort estimations are actually the result of, well, effort. You may feel like someone with complete lack of skill is trying to do your job. If you do, count your blessings: someone has a vision for your product, and is likely to take you places if you just let him. You will eventually settle in one of two conditions: either he becomes technical, or you learn to be assertive. Either way is good.

Quote: "What if we implemented it for just 80% of the cases: will it take 20% of the time?"

 

Code Monkey (Tech = True; Knows = False)

That's not a very good combination. I mean, that's you. And two technical people who do not know what they want is a recipe for stormy weather. You'll be arguing over the best way to do things, but that's not your real argument: you should be arguing about what to do, but neither of you knows that and neither of you will admit it, so you keep to technical arguments. It may be his first role as a PM, maybe he's new to the field or maybe he's just indecisive, but until he charts the course on the map, you'll both be fighting for the steering wheel. Do you think that's bad? Think of the situation when his previous job was doing yours. You have to weather it out, mate, and refuse to enter technical discussions with him. Only then will he be able to concentrate on his real job.

Quote: "How about we'll do a complete rewrite of this module? Why? I don't know!"

 

Puppy (Tech = False; Knows = False)

In some ways, this combination is better than the previous one. Sure, he doesn't know what he wants, and how it's done, but he has you, and you're there to take care of him and explain things to him and to take the blame when things go horribly wrong, so no need to worry, right? This will be a good time to dust off your plans for extensive rewriters and obscure (yet challenging) features. Not that you'll get to finish them. He'll probably change his mind when you're in the middle of it, decide that some new market trend he just heard of is the next big thing, and scratch all your work - unless you can do it in "black-ops time"*. Then you'll be chasing "next big things" for a while, whoring out to all kind of customers with strange demands, and never finish anything until one of two things happens: either he'll get technical, or he'll finally know what he wants.

Quote: "If we'll implement the thingamajiggers for the whatyoumightcallthem we will surely conquer the market."

Migrations

The configurations discussed are not inherent, personal flaws; these are just the current configuration values. A PM can be technical about one product and know nothing about another. He could be passionate and have a clear vision for one product, and will not know what to do with another. He can get tired of a product over time, and he could learn the ins and outs of it enough to handle customer bugs. So ask not what your PM can do for you; ask what you can do to make your PM more tolerable.

---

* Black ops time - time left as a buffer or from tasks finished early. This time is used for doing things the developer really wants done but his PM would never dedicate time for in the project Gantt: rewriting that fiddly locking mechanism, scripting the release procedure, hunting down the memory leak that happens 0.0001% of the time, going over the new guy's code and giving him the what for, etc.

The access architecture of an SDK refers to the types of events generated by it (synchronous, asynchronous), the way it handles API calls (blocking, non-blocking), and the way it processes events (on event, on poll). Different paradigms fit different needs. I usually divide these architectures to 4 main types:

1. Asynchronous events, non-blocking API calls
2. Synchronous events, blocking API calls
3. Event queue, API calls queue
4. Polling for events

Each of these has its advantages and drawbacks, and most importantly, efficient and less efficient implementations.

1. Asynchronous events, non-blocking API calls

This architecture can be called "event driven". It usually includes a main loop (or select loop) that processes all events from the network, expired times and state changes, as well as an extensive set of APIs to initiate application driven events. The application layer is expected to catch all events it may be interested in and respond to them with API calls, which in turn may generate more events to be handled. This is a standard for me, as most protocol SDKs I worked with (i.e. that RADVISION makes) use this architecture.

Advantages

• It is flexible, and allows the application to be multithreaded or single threaded, as well as create multiple internal threads that will all raise events to the application.
• This architecture is very convenient when interacting with other devices or with a user interface. It is also convenient when processes need to be stalled or interfered with.

Drawbacks

• This type of architecture may seem confusing at first, with many events to catch and many APIs to call.
• It tends to break up a process into many segments, each segment to be carried out at (or after) the proper event.

2. Synchronous events, blocking API calls

In contrast to the previous architecture, we'll call this one "process driven". Here, an API call returns only after the requested action is completed (or an error occurred), so there is no need to raise an event that it was done. This means that the application later can call the APIs one after the other in a long chain. In extreme cases, there is no need for a main loop, as even timed actions will block until finished. The events that are raised are synchronous: they are raised during the work process and they require immediate handling.

Advantages

• There is little need to catch events, as APIs simply report success or failure on exit.
• The process' procedure is clear and continuous.
• If working in a multithreaded environment, it allows a thread to follow a process from start to end.

Drawbacks

• Almost always, this forces multithreaded work, as a single threaded access is very inefficient.
• If some form of interaction is required with a user interface or an asynchronous device, threads have to be stalled and a message passing mechanism has to be implemented.
• Many times, SDK or library implementers do not use a pure synchronous or asynchronous architecture, but a mix of the two. This could create a powerful SDK, but could also be very confusing to users unless a clear API naming convention is used.

Event queue, API calls queue

We'll call this architecture "message driven". Anyone who used Windows' window object and its event queue is familiar with this architecture. Events are placed in a single queue, and the application draws them one by one and handles them. Sometimes, there is even a message queue into the SDK - the application, instead of calling APIs, places requests in the queue. More often, a standard (blocking or non-blocking) API is provided for the application's use.

Advantages

• This is the most flexible architecture where it comes to multithreading: the stack can have any number of internal threads and the application can have an unrelated number of threads, and the queue mechanism will keep them out of each other's way.
• Depending on the APIs implemented, this architecture shares some of the advantages of the previous two.

Drawbacks

• This method forces long functions with large switch statements to handle multiple types of messages.
• Parameters passed will usually need to be of a generic nature (void pointers for the C/C++ developers), which limits the amount of static type checking possible.
• Thread usage, while convenient, is not very efficient. May times, two threads will handle events related to the same object and will lock each other out. If these events need to be processes sequentially, there is a risk that the later one will be handled before the earlier one.

There is a way to overcome the last issue. In case the relation of message to handling object is clear (for instance, where the messages are identified by a session id), the messages can be sorted out not to one queue but to as many queues as there are threads, in such a way that messages relating to the same object are sorted to the same queue. This is, in fact, a type of a hash (well, not exactly, but it uses the same principles as hashing functions do). In this arrangement, we achieve two things:

• Messages that should be processed sequentially are inserted into the queue in the order the arrives and will be processes correctly
• each threads withdraws from its own queue, and will only use the objects relating to the messages in that queue, preventing threads from locking each other

Polling for events

We'll call this one "time driven". Here, no events are raised to the application. Objects collect events internally, and if polled, they will process them and report to the application. Some hardware drivers use this approach. API calls may work normally, but more often they also wait for the object to be "triggered" and only then requests are carried out. Our 3G-324M Stack works like this: it will process events, including timed ones only when it is triggered externally from the application.

Advantages

• Threads can be used on a per-object basis, which is very efficient, as all processing and access is done from the same thread.
• As an application, you get complete control on what is running in the system and when - no hidden threads or uncalled for events.

Drawbacks

• It could be confusing to developers, especially if they are used to one of the other models.
• Inefficient when working single threaded. It also forces the application to poll each object in turn.

Books worth reading once are worth reading twice; and what is most important of all, the masterpieces of literature are worth reading a thousand times.

- John Morley

The way I originally heard the saying was "A book not worth reading twice is not worth reading once". I don't think the books on this list are worth a thousand reads, but they are probably worth a second one. I tried to explore them in relation to today's technology: how influenced they are by it, and the influence the technology presented should have on today's technology.

Lord of Light / Roger Zelazny

This novel is a mash up of oriental religion and science fiction. The ruling class of a planet controls advanced technology, enabling not only god like powers, but also enabling "reincarnation" into a new body. A conflict arises in the book between the gods (actually, the first colonists of the planet) if they should continue withholding the technology from the public or share it. All the technology in the book is presented under a religious wrapping, such as TelePresence video conferences ("apparitions") with gods in special prayer chambers. It is now back in print and highly recommended.

(Wikipedia, Amazon)

A Fire upon the Deep / Vernor Vinge

In this book, the galaxy is divided into "zones of thought" that differ by intellectual power possible in them (organic or machine oriented), also limiting the ability to travel in them (bigger machines needed to produce poorer results). In the "deep", simple machinery is all that is possible. The further out you go, speeds and complexity of thought increase until in the outer layers of the galaxy where only (the "transcendent"), god-like intelligences exist. In this way, Vinge works around the problem of what computers can and cannot do: it depends on where the computer is (for a more complete explanation, as well as other books by Vinge dealing with the zones of thought, see Wikipedia link below).

One such god-like intelligence awakens and tries to take over the universe, and our team of heroes sets out to find the only thing that could destroy it, which happens to be on an inhabited planet in an area where advanced technology does not work. The inhabitants of the planet are actually split entities: each such entity is made up of 3 to 6 individual biological bodies, whose thought process is integrated through special sounds emitted by each body in the group. Several times in the book the composition of an entity changes, and the personality of the entity changes as a result. The idea of thought communication is very central to the story, and includes issues of cross-entity interference and remote transmission on radio waves.

Another interesting element in the book relates to machine translation: the heroes are regularly updated by newsgroups from around the galaxy, and as they venture into the depth, the quality of the translation decreases, as does the communication speed. This is a "hard" science fiction story and an epic fantasy story in one.

(Wikipedia, Amazon)

Snow Crash / Neal Stephenson

The hero, called Hiro, sets out to save the world from a virus that is transferred both physically and digitally, by exposure to the virus in the "Metaverse" (where is appears to be white noise, or "snow"). Hiro, "Last of the freelance hackers and greatest swordfighter in the world", sets out to destroy the virus, while different corporations (including a branch of the Christian Church and the Cosa Nostra Pizza Corp., i.e. the Mafia) struggle for control. The book is lined with social and political satire, black humor and references to history, linguistics, computer science and religion. Most notable is the description of the Metaverse, the 3D world that the internet became, and is fast becoming in our real world.

In addition, the book debates the possibility of programming minds (and infecting them with viruses), and discusses culture and religion as programs (or viruses, or immunity systems) running on our biological hardware. This, of course, gives a completely new meaning to communications protocols.

(Wikipedia, Amazon)

Altered Carbon / Richard K. Morgan

This novel is an extension of the old Samurai cinema and Film Noir into science fiction. The psychologically scarred warrior Takeshi Kovacs is hired by a rich man to find out why he (the rich man) killed himself. If the last sentence sounded strange, it's because I neglected to mention that people are regularly backed up to a "cortical stack" and can be "re-sleeved" into a new body. The plot thickens with every page, including femme fatales, double crosses, hidden pasts, ulterior motives, sexual tension and tough-guy humor.

Central to the plot is a faster-than-light transportation method used in the book: the backed up memories and personality of the traveler is transmitted to the destination, where it is sleeved into a local host. The original body waits, frozen, until the traveler comes back: his memories are transmitted back, and copied to his original body. Since such travelers are usually rich and influential, it is very rewarding to hack into these transmissions and find some idea or piece of knowledge worth selling. Creepy thought, eh?

(Wikipedia, Amazon)

1984 / George Orwell

Is 1984 still science fiction? The technology in it certainly is not: a video camera in every television set, and a system to monitor them all. The science fiction here is more of a political science: the ability of a ruling group to prevent all opposition by extreme censorship and a state of perpetual war. Does the ability to censor all information sources still exist? Is there a way to monitor an entire population? We leave a trace wherever we go, online or offline, and even today, even in democratic nations, private correspondences are being monitored for suspected words and phrases. Is the amount of information too great to scan efficiently? Probably. Are methods of encryption readily available? Yes, but they are also breakable. Can a nation implement the political structure defined in 1984? Sadly, yes. This is why it is even more important to read it again. Cameras in every street in London, Google Street View, just consider what they could do in the wrong hands.

Maybe designers of media protocols, taking care of security and authentication, should also take care of the freedom of communication: untraceable, distributed, concealed. Maybe just as a safety measure in case 1984 comes to be.

(Wikipedia, Amazon)

You should know my taste by now - do you have any recommendations to my reading list? What are your favorites?