I have to present a prototype in a couple hours that is really important to my job and the company I work for. I think I'm pretty well prepared, but have been trying to go through any last minute details and bug fixes to make sure nothing breaks horribly well I'm demonstrating it.

It's at a time like this that my brain decides to recall a poem I wrote in the third grade. Now, I'm not really sure how I got there, but now that I have I decided I'd write it down because I still like it. :)

Tomorrow is Today, if Yesterday had never been,
Today is a day that will never come again,
Now is the the time that always will be,
Time is the variable, only the mind can see.

Not bad for a third grader, huh? ;) Well, back on track I'm really excited about this demo as it is the largest application I've developed yet utilizing jSeamless and this demonstration is about getting more buy-in for the product, the framework I've written, and jSeamless from the company I work for. Next week I'll be able to start adding massive new features to jSeamless (I couldn't until this demo was completed for fear I'd screw something up).

Anyway, this will hopefully be a short day for me so I think I'm going to go home and spend the rest of the day with my wife...I love Friday. :)

Adobe Flex 2.01 is a very good framework and it is so much better than practically any other web-based UI framework in existence today, but there are so many bugs in the code and so many restrictions that are very difficult to get around I'm locked into a love and hate relationship with it.

I'm using Flex for the reference implementation of jSeamless and it is going quite well over-all, but I'm finding myself re-writing component after component because of either bugs or lack of features. The good thing about this though is that the entire Flex source code is available within the SDK, so I can see exactly what they are doing and how they are restricting me or causing bugs to occur.

My single biggest complaint about Flex is their complete lack of threading "support". That is not to say it is single-threaded. Quite the contrary. Everything is asynchronous in Flex, but thread-safety is an unknown term to the Flex team I believe. There is no way to synchronize, lock, or maintain good concurrency in the system and many a crash has been due to this. In jSeamless I have a full system I wrote to offer some concept of synchronization and though extremely limited because of ActionScript 3 support not being there, it works pretty well.

I'm about to completely re-write the way Effects are called in the Flex implementation of jSeamless because it is causing errors to occur and also offers no way of disabling effects. I'm a Java developer and writing in ActionScript 3 is really not my idea of a good time, so every line of code increases my frustration.

On the bright side, jSeamless has far exceeded the capabilities of what Flex can do because of its "flexibility" and for that I'm extremely thankful.

I know that seems like a strange question to ask, but it's one I often ask myself. In many ways I've been extremely successful throughout my life, and it occurs to me that many of those successes were good successes, and many of them were bad successes. Most of the time it's easy to tell the difference. Sometimes, however, it's very difficult to discern.

I've been feeling this way recently regarding jSeamless. I believe it's one of the greatest development endeavors of my life thus far and have no intention of abandoning it, but it is now beginning to develop a following of users, which is great, but the majority of these users simply use the API and then post when something is missing or broken. Don't get me wrong, I have no problem with this, but I'm getting extremely bogged down with providing functionality for these users instead of them helping and committing to the project themselves. I believe in the long-run it will get better and eventually I'll have some strong developers that are willing to help. For now though, it's draining to spend all day at work writing code to support them, and then coming home and writing code to support the jSeamless community.

I guess a project has to catch on at its own pace, I just wish there were more people interested in helping. jSeamless is becoming a large project and I'm just one person. I often brag about how much this one person can do, but I realize as well as anyone that my limitations are definitely there.

It saddens me these days to see so few programmers that question the way things are done and simply accept as the best way to do things what is considered to be the standard. I fear innovation is being lost in this generation of developers since instead of questioning and trying to make new and better ways to accomplish tasks they simply take what is "standard" and conform to it.

Someone told me the other day, "I come from the school of thought, there's nothing special about me", and I think that's becoming more and more the norm. If everyone approached technology this way we could never move forward. Innovation is necessary for advance and the programming community is one of the most necessary places for this to occur. We become too comfortable with the coding practices of today and since we aren't forced to push beyond, we settle to what we know.

To be honest, this is not something I've considered to be a problem until I started working on the implementation in jSeamless of it. Servlet Sessions are just fine for the majority of web applications but I began to realize that they are inherently flawed conceptually. The first problem is that multiple tabs in a browser (even multiple windows in Firefox) rely on the same session. If you are trying to replicate functionality like a regular desktop application this is problematic.

Have you ever opened up two instances of Notepad? Did you ever dream that the second instance would be using the same session as the first? Why should this be the case in web applications?

I've said this before, but companies push their developers to write web applications that mimic functionality of a desktop application. Why do they do this instead of just deploying applications to their users? Well, there are still a few good reasons for this, but internal applications there's no other reason than it makes management happy that they can add "web" to everything. Yes, I'm probably shooting myself in the foot proclaiming such things as the majority of jSeamless' success is because it is so powerful for web applications. This is actually the primary reason I created it. I'd personally much rather be doing application development and with jSeamless now I can.

Back on topic, I realized that determining "session" based on what window was open was practically impossible to do as there is no good way of determining any sort of window or tab id that differentiates it from another. However, by forcing immediate redirects to a generated id in the URL it does allow me to do so. Yes, it's sort of jumping back in time to pre-cookie days, but it's really the only way to go. This does have some nice advantages though in jSeamless. First, it allows bookmarking of a "session" and reconnecting to it later and picking up where you left off. Second, it does allow good differentiation from one session to the next. So if you open a new window or tab you can reliably create a new "session" for the web application you're connecting to. This is implemented now in jSeamless and will be coming out in Beta 4, so we'll see how well received it is. :)

There has long been a problem with getting information from the server to the client real-time in web applications. There are several hacks out there for making this happen, but most of them revolve around some idea of polling or server push.

These have significant flaws and a while back I sat down to come up with a better solution. I believe I've done so, and I've called it "Delayed Ajax". Now, the name might lead you to believe that it's going to be quite the opposite of real-time, but hopefully I can explain this well and you'll see why I chose the name and why it is the best option for server to client communication available without going to a pure socket connection.

This is actually an extremely simple idea and perhaps others have been doing it for years, but after a lot of searching I have yet to find anyone (correct me if my google skills are lacking) that has been pushing this idea. The idea is founded on Ajax polling, but with a slight twist. The draw-back with polling is that you either poll very fast and create a lot of wasted bandwidth, or you poll slowly and messages from the server to the client are very slow to arrive.

Okay, so here's the twist. Instead of the client polling, the server immediately responding with message(s) or nothing, the client processing and then waiting a few seconds and doing it again, I put the wait-state on the server instead. The client essentially sends an Ajax requests and forgets about it. The server accepts the request and if there is anything waiting in the queue to go to the client it immediately returns. However, if there is nothing in the queue there is a timeout period (typically around ten seconds) that it holds onto the connection without returning anything waiting on data to come through. As soon as anything hits the queue it immediately fires it out to the client and returns. This gives perfect real-time Ajax communication from server to client The client has no waiting, it fires and forgets but when the callback gets hit it will process the data from the server and then immediately fire again.

In my case I'm handling the server-side aspect with a Servlet, but this can be handled in practically any server-side language that supports multithreaded requests (since multiple requests have to sit idle in a thread waiting for data into the queue).

I've long procrastinated setting up a blog, but since I'm being bombarded by ideas in my head and my forum posts are becoming more and more off-topic I've decided to set up a blog for my random ideas and rants to at least get them out of my head.