« October 2003 | Main | December 2003 »

November 2003 Archives

November 13, 2003

Browser Enabled LOAF

After reading about how We need LOAF! it struk me that all of these implementaions are server side, and we need at least some sort of a client side acces to LOAF. So I proudly present Browser Enabled LOAF. It should be fully ECMA262 compliant so it should run on all of the latest versions of IE, Mozilla, Netscape, Opera, and OmniBrowser (for you Mac/NeXT folk out there).


P.S. Does anyone know of a good patent attorney? I believe that my melding of LOAF with a Web Browser is Patentable. I just hope there's no prior art. Don't Worry though, I'm just patenting it so Microsoft doesn't patent it first. The only companies I'll extort money from are those who abuse LOAF or don't adhere to established LOAF standards.

November 14, 2003

Question About Employee IP Agreements

So if I sign away all the IP I create on company time or equiptment just how far does that extend? If I order a doll for my niece from Amazon does the company then own the intelectual rights to the reciept that Amazon generates? And if so, when at some point I am no longer with said company and I need to access that recipt to return said doll, do I violate the terms of the agreement to not use the companies IP after I separate from said company? Hmm...

November 15, 2003

The many lives of javax.swing.Action

Gregg Bolinger been using swing for a while mentioned in My Approach to Menu's in SWING about how he extends and uses the Swing action alot. After being buried deep in Swing for nearly two years now I have to concur: Actions are more importiant than you may initially think.

For the Swing code I've written at my job I use Actions to back the actions of menu items, toolbar buttons, popup menu items, some of the regular old buttons, and even handeling Drag and Drop actions too! (Since the drag and drop is another way to invoke a menu action I just wire in the call to the actions for a successful drop).

Like Gregg I've overloaded abstract action, but I've gone crazy with stuffing in the standard behavior. First I populate all of the action values from a resource bundle. This allows for easier I18n of the action and it also keeps a lot of the related actions visual looks in the same file. This is handy when someone decides they don't like the menu accelerators you've selected or that all of te Icons need to be re-done and stored in a differnt place Next I populate a large amount of standard information into the value cache of the action itself:

  • Name
  • Location in the Menu Bar (i.e. file/new/widget or help/about
  • Location in the Tool Bar
  • Location in standard Pop-up
  • Toggelable (creates checkbox menu item or toggle toolbar button)
  • Asynchronous (spins a thread for the action)
  • Icon (along with rollover and selected varients)
  • Tool Tip
  • Mnemonic
  • Accelerator

And that's just what I can remember early in the morning on a weekend. I also provide standard methods to get a menu item and toolbar button out of the action so I can handle things like the checkbox menu items and global options such as show/hide menu icons and tooltips. I also try and limit any code that does any user initiated actions to live in the action methods of these objects.

By doing this it keeps a lot of the non-gui code out of the gui and I can stress out about bizzare JTable behavior without tripping over a database call to delete a row.

November 17, 2003

Weblog Polling

Just last week I got this month's issue of the ACM's Queue Magazine. This month's focus is Instant Messaging and one of the articles was an op-ed/advert for IBM's Community Tools. One of the most interesting tools I though was PollCast, which is basically IM polling. Reading the use scenarios was fascinating, but then I got to thinking... (dangerous, I know) could something like this be done for Weblogging? Quickly I came to the conclusion that yes it could.

Adding polls and responses to polls is something that could totally be done within weblogging, and in fact could be considered an extension to popular syndication formats such as Atom and embedded in weblog software and possibly readers. At a low level there would be some extra elements in the entry element of a weblog post in Atom or via other entry characteristics that tell the user agent that a poll is part of the weblog entry. In these would be essential items such as the question, the allowed set of answers (along with a current summary of the results), possubly extra data such as the allowed timeframe to vote within, and (most importantly) URIs for an API call to do trackback/backtalk like pings to the poll. The last piece is what I believe is the most novel part of this concept: To vote in the poll you would have to have a weblog entry of your own voting for an answer in the poll. Another URI could be to list the specific votes like a trackback list, so users can explain their votes if they fell the need. And this adds something totally missing from current web polls: transparent accounting and traceability. Anyone with a polling enhanced aggregator can examine the poll results themselves and even tally the votes themselves.

The poll sponsor side could be as simple as a typical weblog entry with two added features. For the HTML rendering of the entry the normal entry would be followed or prefaced by a nice rendering of the poll question and progress, along with links to the votes themselves like a "comments" page. An auto-discovery link would also be present for polling enabled clients or smart JavaScript bookmarks like Moveable Type creates. This is so the viewer can vote immediately if they have a ballot/blog. For the syndication feed there would need to be the aforementioned elements describing the poll in addition to the other elements that are part of a normal entry.

The real complexity of this comes in the sponsor implementation itself. The sponsor would need to be aware of the voting trackback links and would need to store the information and know to update the syndication and html pages. For blog systems where everything is dynamically generated then this isn't quite the same issue, bot for static hybrids they would need to trip some re-generation codes, however clever use of IFrames could fix that.

As for the poll ballot sites, this is where more flexibility exists. But for the transparency to work there would need to be some indication of how they voted. One possible HTML rendering could show the poll as it would appear on the sponsor site except highlighting the particular ballot entries vote. The could also including a href to the of the poll. Perhaps the same auto-discovery links the sponsor may also be present to allow the viewer to vote themselves without ever having to visit the sponsor site. Similarly the syndication feed would need to include an element indicating what the vote for that ballot was and perhaps the same links back to allow second or third generation voting.

The more I think about this the more complex it gets on the server side, and the more seamless it could seem to the user with the right tools, but there enters the network effect. And I don't have enough exposure to any of the blogging systems or clients to effectively code a proof of concept (not to mention lack of time). But in a perfect world where this existed it could actually be usefull. Perhaps in addition to JDJ, JavaPro, Jolt, and JavaWorld offering awards at JavaOne perhaps there could be the java.net WebLog awards awards, the advantage being that no accusations of secret ballot box stuffing or editorialized awarding occuring snice everyone can see fot themselves the ballots with the haning chads!

November 18, 2003

IBM Move Fills in Eclipse Hole

Almost year ago I posted a review and comparison of NetBeans and Eclipse. The ultimate end for me was to stick with NetBeans because it had a visual gui designer and Eclipse didn't (an essentail job function of mine). Well, that looks to be changing. IBM will start it off by donating its Visual Editor from the WebSphere Studio line to the Eclipse project for JFC/Swing editing, and other companies will be extending it to support SWT. This perhaps may explain why SWT Designer sold itself to Instantiations earlier this week.

This basically leaves refactoring as the bigest distinguishing feature of Eclipse, and Code Folding for Netbeans once 3.6 ships.

November 19, 2003

Python one-ups Java in Consumer Land

So I spent most of the afternoon setting up and transferring data for my new HP computer (a250n for those who care). Boy you wouldn't believe the junk that comes pre-installed with a consumer model. But when I was uninstalling the junk that had unistallers I was astonished to see that one of the items that came pre-installed was Python 2.2.1 and the win32 extendsions. But Java wasn't. Python, yes Python was on my consumer PC. I don't know why, I can't find any *.py* files.

So Java, with sun behind it has to play second fiddle to Pyton being the pre-installed suprise. Who'de of thunk?

November 20, 2003

NetBeans Feels the Refactoring Heat

In addition to starting up an interim release 3.6 that NetBeans initially didn't consider doing they have also recently proposed major changes to the 4.0 plan. Originally a re-worked Projects system was to be the centerpiece of the 4.0 release, but that has for the most part been scrapped. The big reasons pusing this? It was consuming too much resources that they felt should go to requested features such as code folding and (no suprise) refactoring. Some projects stuff will come in but most of the projects bugs will be closed as WONTFIX.

A real IDE arms race is heating up now that it seems that NetBeans realized that this is a battle that is winnable and worth fighting. But honestly I don't see there being only one true IDE for java like Visual Studio is for Windows development. Combine this news with the recent additon of a Visual GUI Editor to Eclipse means that Netbeans 4.0 and Eclipse 3.0 should have very solid parity with no clear advantage to either. Things will get very interesting if the common IDE plugins JSR gets supported by both as well.

November 21, 2003

Thick Client : Thin Client :: Red Pill : Blue Pill ?

Now that the Web has finally invaded just about every corner of life and the magic of "thin client" has been applied to every conceivable application we can finally as ourselves the question "is this the right thing to do" rather than "can we" or "how do we." the answer to the second is "yes" and with some Googling the answer to the third is within easy grasp. But these two beg the first question, of "should we." At my company we started out our first pass on the GUI as a pure think client DHTML nirvana. At the time the think client kool-aid was quite strong and everybody bought into the vision of it. We didn't have any real serious discussions on any non-html solutions. We have since started going down the swing path for various reasons. It wasn't a bad thing we started out thin, because if we started out thick we would have certainly have been asked the question about why we don't just do it in HTML. Now people can see the difference and for waht is wanted it is a real value.

But thick isn't always the answer. Sometimes thin is the way it should be done. But when and which? Here is a bullet list based on some of my experiences, dating all the way back to when NetDynamics was sold by a company called Spider Technologies.

  • Scale - This is actually two questions, with different answers for each extreme based on the way you ask it.
    • Number of Users - How many users are going to be using this application? If it is large (hundreds to thousands per instillation) then a thin client avoids messy install issues. If it is small then either way.
    • Amount of Data - How much data is the user expected to handle. It's not about how much water is coming through the hose but how big the nozzle is. To much data coming through a thin client is like a fire hose. But on a thick client it can look like a meandering river. Lots of data at once means go thick
  • Interactivity - Is the interface meant to be highly interactive? We're not talking just mouse overs and hovers. Resizable and removable column headers have a hight cost associated with then in a thin client. Similarly a frequent need to update data on the server can place a heavy load on the server application if done poorly, even if done smartly. A thick client can more easily update a small piece of data without dragging back across the wire a large amount of strictly visual effects, such as adding a new node to your typical tree control.
  • Rich UI Controls - How much control do you need over the UI controls? Editable ComboBoxes/SelectBoxes are one example that are all but impossible to do well in HTML. A rich table control with sortable columns that can be dynamically resized and have columns removed showing thousands to possibly millions of rows can be done with HTML through various HTML and serving tricks, but the tend to work better when thick. Some controls can be emulated "good enough" in HTML with scripting, such as calendar selects and formatted fields, so that may work for thin. But plain old goofy controls will requires some meat on them bones.
  • Frequency of User Use - How often is the typical user going to use it? If it's once a month they won't endure a 10 minute install, like your typical online banking app. But if it is continually used they may want a client image, like an Instant Messenger client. Some frequently used apps can be done well with a thin client, but that's because the UI is simple

Thin clients are good, but I think they are being over-done. When I hear of people writing a UI that 10 people at each large client will be using all day with rich table controls and massive amounts of data pushed through it being written as a DHTML web app it makes me want to take the blinders off and introduce them to old friends like Applets and new friends like WebStart. After all, thick is the big trend.

November 24, 2003

Thick and Rich Like Snickers Cake

It appears that I've been getting some drubbing over what I call thick and thin. One coward who wouldn't leave a real name in the comments section stated that

Are you implying the Swing == thick ?????
This is completely false.A Swing client could be thick or thin.

One of the things I learned in school is to make statements that don't contradict themselves, like calling something completely false and then immediatly stating that part of the time it is true. This is predicate logic, typically covered in the sophomore year of most CS departments, which the responder must have been too drunk to remember. Mr. "Look at me I'm Anonymous!" should have just said that my choice of words was imprecise in his opinion.

Neil kindly pointed out that Sun has been using the term "Rich Client". I always thought that term was a reaction to the (formerly) negative connotation of a thick client, when they were client/server applications (such as your typical PowerBuilder app). Perceiving it to be marketing fluff I had quickly expunged this term from my vocabulary. But the lines and definitions between thick and thin are getting very blurred and stuff like WebStart is even obliterating some of those lines.

But sometimes things can be too rich. If you ever cook a Snickers Cake be sure to use semi-sweet chocolate chips instead of milk chocolate chips. That was a little too rich and thick.

About November 2003

This page contains all entries posted to ... And They Shall Know Me By My Speling Errors in November 2003. They are listed from oldest to newest.

October 2003 is the previous archive.

December 2003 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33