Since nobody reviewed my talk, I'll try to get the ball rolling myself.

First problem with my talk was that I didn't resolve technical issues in time. I spent 25 minutes doing this, but that doesn't excuse me from responsibility. Speakers should be required to do this a day in advance unless they have a very good reason not to.

I was deconcentrated, but still, my delivery wasn't focused enough and was completely flaccid, non-engaging. Talks shouldn't sound like someone is reading ingredients on a can.

I probably tried to cram too much into one session which meant my talk was mostly too shallow to be really useful. It's better to pick preferably one big enough problem and deal with it well (as I was told Comet presentation did).

There are probably other things I didn't do well, but it's getting to late for me to remember and I'm sure somebody else can continue from here :)

Don't be too hard on yourself Marko. There were equally dry presentations that held my interest due to content. like the OAuth one for example.

However, for me, as a developer, I was interested in the "how to". when it got to that section, I perked up... but then I heard "get Brian to write it!". ...and that was pretty much it.

Finally, I think that browser plugins themselves aren't [ or at least shouldn't ] be the future for the web anyways IMHO... it's a highly unstable platform to begin with, isn't it? Why write code that depends on the browser if you can avoid it?

Thanks Joel for your comment.

I agree with you that browser plugins shouldn't be the future of the web and I am an optimist enough to think they aren't. But until we get a general plugin infrastructure for most if not all websites, they can be only usable option.

There wasn't enough time to talk more deeply about extension development if I spent less time on other issues. Our experience with extension development is that getting a working extension can be a lot of work, but maintaining it for newer versions of browser in general isn't.

There are also differences between browsers. Firefox for example has a fairly good infrastructure and tools and you can get an extension working quite quickly. Explorer on the other hand has nothing, so it takes more effort and familiarity with Windows platform.

Also, as I explained, but certainly not clearly enough, we use extension only as a loading mechanism. The whole purpose of our extensions is to recognize page on which we want to insert widget and insert appropriate Javascript loader file. Extension has to be browser specific practically by definition, but it is also the only browser specific code we have. JS loader file and rest of the widget aren't.

In any case, I will try to get us opening our code so it could be used as a starting point for others.

That said, I do use a few browser plugins myself... because they are so useful. FireFTP for example, Venkman, etc... but every time I upgrade Firefox and see that message about version / plugin compatibility problems I cringe.

wait a sec... are you saying that the javascript is NOT browser specific? are you using Aspect Oriented design to insert code into the page that is rendering? or what?

Sorry for late answer. I spent yesterday traveling home.

Well, sort of to both questions. You can't really write any significant piece of Javascript without hitting at browser specific parts. You may offload part of this burden on libraries like jQuery, and we do, but with complex enough problems never all of it. But I better start with high-level overview.

Our extensions/plugins are made of two parts. A platform specific loading part like Firefox extension or WordPress PHP plugin, purpose of which is to insert loader.js into page. How this part looks like obviously depends on platform in question, but that's more or less everything they do.

Loader.js is a short javascript that loads widget by inserting a couple of Javascript files and a couple of CSS files. These 4 files together with images form the other part of the extension, widget itself. One JS and one CSS are generic, which means absolutely the same on all platforms and for all browsers. They implement skeleton of widget together with its "brains".

Then we also have a blogging platform specific javascript file and CSS, purpose of both being to integrate our widget well with specifics of given blogging platform.

We don't have browser specific files, but we do sometimes have to check what facilities browser offers and take that into an account.

I don't know enough about AOD to call it such, but code is indeed structured to provide aspects to which platform specific code is written. Example would be a function that finds an editor on page and returns an appropriate object to work with. Since there are many Javascript rich text editors out there and sometimes none on page, we have to handle this platform by platform.

Hopefully this answers your question, but please let me know if anything is unclear.