Dabo 0.9.0 Released

We are proud (and relieved!) to finally release Dabo 0.9.0, the first official release of the framework in six months. We haven't been taking it easy during that period; rather, we made some changes that clean up some weak spots in the codebase, and as a result can offer a much more solid framework, and are on course for a 1.0 release in the near future.

To do this, we made some decisions that break backwards compatibility. We dropped support for Python versions earlier than 2.4, and wxPython versions below 2.8. Supporting everything is nice to aim for, but completely impractical.

There is also a major addition to the framework: the ability to deploy Dabo applications as true web apps. Imagine: being able to develop a rich internet app using nothing but Python on both the client and server! It's still early in the development process, so it's lacking a lot of the supporting tools, and almost no documentation has been created, but that will be coming in the next few weeks/months. When you deploy your app as a web app, all data access and business logic is on the server, and the framework automatically handles the communication between the client and server. The framework also automatically grabs file changes from the server, making UI updates seamless and quick. Lots more interesting stuff will be happening in this area in the near future, so stay tuned!

If you're not already familiar with Dabo, we're the premier open source framework for developing desktop (and now web!) applications in Python. We make the difficult stuff like binding databases to UI controls simple.

You can grab the latest version from http://dabodev.com/download

A fairly comprehensive list of the changes we've made since the last release can be found at http://svn.dabodev.com/dabo/tags/dabo-0.9.0/ChangeLog

And if you want to learn more, join our email list: http://leafe.com/mailman/listinfo/dabo-users

-- Ed Leafe

Ed Leafe wrote:

We are proud (and relieved!) to finally release Dabo 0.9.0,

Congrats!

There is also a major addition to the framework: the ability to deploy Dabo applications as true web apps.

From your description, it sounds like you're building client-server networked apps, not web apps.

I think most people define a "web app" as one where the client runs in the browser. Flash and JAVA can kind of confuse things, but if you need a wxPython client, I don't think it's a web app.

If you are using REST to communicate with the server, than it's a "web service"

Or I may have misunderstood your description.

In any case, that's not to say that what you are doing is not very nice!

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Don't worry, it's not uncommon when talking about an entirely new approach.

  Your comment about having to run in a browser to be a web app is probably the sticking point. The point about a browser is that it grabs the most recent version of a page from a server and displays it to the user. Dabo does the same thing. It doesn't require you to install anything once the browser is installed; we're creating a similar app that will likewise not require anything but that one app to run any Dabo web app.

  Kevin Dangoor gave an excellent keynote at PyWorks last month, in which he talked about the evolution of web apps from simple read-only HTML to forms to basic Javascript to AJAX to complex JS frameworks. His point was that over time the trend is clearly toward richer and richer client experiences (hence the rise of Flash).

  My problem with this is that we are now doing more and more of our coding in Javascript and ActionScript, and less and less in Python. I've done a lot of that, and I much prefer Python to Javascript. So that's why I started working on the reverse approach: take a rich desktop UI and add to it all of the things that make web apps so attractive: zero deployment, seamless updates and server-side control of logic and data access.

  I hope you'll be coming to PyCon 2009; I'm planning (if the PyCon gods so deign) to demonstrate this in a session there.

-- Ed Leafe

···

On Dec 10, 2008, at 2:17 PM, Christopher Barker wrote:

There is also a major addition to the framework: the ability to deploy Dabo applications as true web apps.

From your description, it sounds like you're building client-server networked apps, not web apps.

I think most people define a "web app" as one where the client runs in the browser. Flash and JAVA can kind of confuse things, but if you need a wxPython client, I don't think it's a web app.

If you are using REST to communicate with the server, than it's a "web service"

Or I may have misunderstood your description.

Hello Ed,

but I dont understand yet… the new Dabo approach is: something like a browser? or your make your own webserver based on mod_python o wsgi or whatever?? or you try to embed wxpython control inside of … what? browser? DaboWebApp? :smiley:

···

2008/12/10 Ed Leafe ed@leafe.com

Don’t worry, it’s not uncommon when talking about an entirely new approach.

    Your comment about having to run in a browser to be a web app is probably the sticking point. The point about a browser is that it grabs the most recent version of a page from a server and displays it to the user. Dabo does the same thing. It doesn't require you to install anything once the browser is installed; we're creating a similar app that will likewise not require anything but that one app to run any Dabo web app.




    Kevin Dangoor gave an excellent keynote at PyWorks last month, in which he talked about the evolution of web apps from simple read-only HTML to forms to basic Javascript to AJAX to complex JS frameworks. His point was that over time the trend is clearly toward richer and richer client experiences (hence the rise of Flash).




    My problem with this is that we are now doing more and more of our coding in Javascript and ActionScript, and less and less in Python. I've done a lot of that, and I much prefer Python to Javascript. So that's why I started working on the reverse approach: take a rich desktop UI and add to it all of the things that make web apps so attractive: zero deployment, seamless updates and server-side control of logic and data access.




    I hope you'll be coming to PyCon 2009; I'm planning (if the PyCon gods so deign) to demonstrate this in a session there.

– Ed Leafe


Saludos / Best regards

Mario Lacunza
Software Architect - Webmaster

Email: mlacunza [AT] gmail [DOT] com
http://www.lacunza.info
Lima - Peru

As I said, the docs are sparse, so it's hard to understand without a full explanation. I plan on spending some time writing some more informative docs over the next couple of weeks.

  Right now the server part is based on Pylons, but that's just because I had Pylons installed and am familiar with it. There is nothing done on the server side that couldn't be done with any other web server.

  The "browser" (I think we'll call it a 'launcher' or something else to avoid even more confusion) is an "frozen" executable created with something like py2exe. It contains everything needed to run any Dabo app. You enter a base URL, and the server presents a list of apps available on it. Or you can pass the specific app URL, and the app files are copied to your machine, like a browser copies HTML, CSS, JS, etc. Dabo UI files are fairly light-weight XML, so this copying is not much different than what a web browser would need to do. Once the app is on your machine, it will check the server when needed to see if there are any changed files, and just download what's changed. So a change to your UI doesn't require a time-consuming update process, as with most desktop apps. It's no different than if you were to change the HTML on a web page.

  The app runs just like a Dabo desktop app, but all data access and business rule validation is done via calls to the server. Right now those calls are synchronous, but I plan on adding an asynchronous option soon.

  I hope that this makes a little more sense...

-- Ed Leafe

···

On Dec 10, 2008, at 2:50 PM, Mario Lacunza wrote:

but I dont understand yet.. the new Dabo approach is: something like a browser? or your make your own webserver based on mod_python o wsgi or whatever?? or you try to embed wxpython control inside of ... what? browser? DaboWebApp? :smiley:

Ed Leafe wrote:

... snipped ...

    I hope that this makes a little more sense...

Yes, it does. And it sounds very cool. In a way, I suppose you could say that you've written a "browser" that uses python and XML, rather than HTML+JS.

However, and this is purely a semantic argument -- a "web app" is an app that runs in t "standard" browser, which means HTML at the core -- or, if you want to stretch the definition a bit, an app that runs in standard browser plugin (flash, etc).

I don't know what to call what you've done -- it's your chance to coin a new term!

Does it use http to communicate with the server?

> The point about a browser is that it grabs

the most recent version of a page from a server and displays it to the user.

well, yes -- but the other point is that it's a standard piece of software, with multiple implementations (incompatible , of course!), and that it uses primarily html. Those are key features of what folks expect when they say "the web" or "web app".

    My problem with this is that we are now doing more and more of our coding in Javascript and ActionScript, and less and less in Python. I've done a lot of that, and I much prefer Python to Javascript.

I agree, but we do so because Javascript is in all modern browsers, and most folks have browser installed. This is key. For example, we work with the US Coast Guard a lot -- it takes them literally a year (or more) to get permission to install a new piece of software on their systems. By then there's an update available, and the permission process starts over -- if we can deliver an app that run inside the browser they already have, we can avoid all that.

Anyway, semantics aside -- this is very cool!

Any yes, I do hope to go to PyCon, but I don't know if my proposal as been accepted, and I don't know if I can get the funding.

By the way, my proposed talk is about embedding a web-app (html+Javascript+server) in a wxPython app to make it like a desktop -- the reverse path of yours!

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

However, and this is purely a semantic argument -- a "web app" is an app that runs in t "standard" browser, which means HTML at the core -- or, if you want to stretch the definition a bit, an app that runs in standard browser plugin (flash, etc).

I don't know what to call what you've done -- it's your chance to coin a new term!

  I guess up until now a 'web app' and a 'browser app' were one and the same. I'm trying to broaden that. Also, most browser activities are with web pages, not necessarily web apps.

  At the same time, I don't think that there will be a wholesale dropping of HTML and Javascript anytime in the foreseeable future no matter what "cool new thing" came along. It's simply too ubiquitous, and it would be silly to try to change that. That's not what I want to do. I was kind of inspired by Adobe Air, which creates rich client apps using Flash but without the browser. This would be rich client apps in Python/wxPython, and also without the browser.

Does it use http to communicate with the server?

  Yes.

> The point about a browser is that it grabs

the most recent version of a page from a server and displays it to the user.

well, yes -- but the other point is that it's a standard piece of software, with multiple implementations (incompatible , of course!), and that it uses primarily html. Those are key features of what folks expect when they say "the web" or "web app".

  Probably true. I'm not too hung up on the terminology; I simply wanted to marry all the advantages of a rich client UI like the one that wxPython give us with the advantages that a browser-based approach has: no deployment hassles for either the initial running of an app or any subsequent updates.

   My problem with this is that we are now doing more and more of our coding in Javascript and ActionScript, and less and less in Python. I've done a lot of that, and I much prefer Python to Javascript.

I agree, but we do so because Javascript is in all modern browsers, and most folks have browser installed. This is key. For example, we work with the US Coast Guard a lot -- it takes them literally a year (or more) to get permission to install a new piece of software on their systems. By then there's an update available, and the permission process starts over -- if we can deliver an app that run inside the browser they already have, we can avoid all that.

  That's cool - something like wxPython app wouldn't be very useful then in that situation. There are lots of places that disallow Flash and/or Javascript, so you have to code to what your target can use.

By the way, my proposed talk is about embedding a web-app (html+Javascript+server) in a wxPython app to make it like a desktop -- the reverse path of yours!

  Sounds interesting. Let's just hope that we both get accepted, and that they don't schedule us in the same time slot! :wink:

-- Ed Leafe

···

On Dec 10, 2008, at 4:09 PM, Christopher Barker wrote:

Ed Leafe wrote:

However, and this is purely a semantic argument -- a "web app" is an app that runs in t "standard" browser, which means HTML at the core -- or, if you want to stretch the definition a bit, an app that runs in standard browser plugin (flash, etc).

I don't know what to call what you've done -- it's your chance to coin a new term!

    I guess up until now a 'web app' and a 'browser app' were one and the same. I'm trying to broaden that. Also, most browser activities are with web pages, not necessarily web apps.

I have to agree with Chris on this one: the common usage of "web app" that's
been around for several years is "browser-based app". Calling what you
are doing a web app will just be confusing, and I'm sure it will not change
the common usage of "web app".

What you have is a client-server app, but if you want to give it a sexier
name, invent a new one! :wink:

    At the same time, I don't think that there will be a wholesale dropping of HTML and Javascript anytime in the foreseeable future no matter what "cool new thing" came along. It's simply too ubiquitous, and it would be silly to try to change that. That's not what I want to do. I was kind of inspired by Adobe Air, which creates rich client apps using Flash but without the browser. This would be rich client apps in Python/wxPython, and also without the browser.

Maybe "rich client app" would be buzzy enough?

Does it use http to communicate with the server?

    Yes.

That gives justification to call it something like a
"rich client for web services" (at least that doesn't have a
common usage that I know of ... ;).

> The point about a browser is that it grabs

the most recent version of a page from a server and displays it to the user.

well, yes -- but the other point is that it's a standard piece of software, with multiple implementations (incompatible , of course!), and that it uses primarily html. Those are key features of what folks expect when they say "the web" or "web app".

    Probably true. I'm not too hung up on the terminology; I simply wanted to marry all the advantages of a rich client UI like the one that wxPython give us with the advantages that a browser-based approach has: no deployment hassles for either the initial running of an app or any subsequent updates.

Which has nothing to do with the web per se, although browser-based
apps exemplify it. :wink:

   My problem with this is that we are now doing more and more of our coding in Javascript and ActionScript, and less and less in Python. I've done a lot of that, and I much prefer Python to Javascript.

I agree, but we do so because Javascript is in all modern browsers, and most folks have browser installed. This is key. For example, we work with the US Coast Guard a lot -- it takes them literally a year (or more) to get permission to install a new piece of software on their systems. By then there's an update available, and the permission process starts over -- if we can deliver an app that run inside the browser they already have, we can avoid all that.

    That's cool - something like wxPython app wouldn't be very useful then in that situation. There are lots of places that disallow Flash and/or Javascript, so you have to code to what your target can use.

The situation Chris describes holds for a lot of large organizations,
particularly government ones, which is another reason why the common
usage of "web app" refers to browser-based apps, as in "Can that be done
as a web app so we can deploy it here in a reasonable amount of time?"

By the way, my proposed talk is about embedding a web-app (html+Javascript+server) in a wxPython app to make it like a desktop -- the reverse path of yours!

    Sounds interesting. Let's just hope that we both get accepted, and that they don't schedule us in the same time slot! :wink:

Yep -- all the semantic stuff aside, what you're doing sounds really
interesting, Ed!

Cheers,
Steve

···

On Dec 10, 2008, at 4:09 PM, Christopher Barker wrote:

I think in the Java/Eclipse world this is referred to as a "Rich
Client Platform" ... or atleast it sounds similiar.

g.

···

On Wed, Dec 10, 2008 at 6:05 PM, Stephen Waterbury <waterbug@pangalactic.us> wrote:

Maybe "rich client app" would be buzzy enough?

Ed Leafe wrote:

···

On Dec 10, 2008, at 4:09 PM, Christopher Barker wrote:

However, and this is purely a semantic argument -- a "web app" is an app that runs in t "standard" browser, which means HTML at the core -- or, if you want to stretch the definition a bit, an app that runs in standard browser plugin (flash, etc).

I don't know what to call what you've done -- it's your chance to coin a new term!

    I guess up until now a 'web app' and a 'browser app' were one and the same. I'm trying to broaden that. Also, most browser activities are with web pages, not necessarily web apps.

    At the same time, I don't think that there will be a wholesale dropping of HTML and Javascript anytime in the foreseeable future no matter what "cool new thing" came along. It's simply too ubiquitous, and it would be silly to try to change that. That's not what I want to do. I was kind of inspired by Adobe Air, which creates rich client apps using Flash but without the browser. This would be rich client apps in Python/wxPython, and also without the browser.

Does it use http to communicate with the server?

    Yes.

> The point about a browser is that it grabs

the most recent version of a page from a server and displays it to the user.

well, yes -- but the other point is that it's a standard piece of software, with multiple implementations (incompatible , of course!), and that it uses primarily html. Those are key features of what folks expect when they say "the web" or "web app".

    Probably true. I'm not too hung up on the terminology; I simply wanted to marry all the advantages of a rich client UI like the one that wxPython give us with the advantages that a browser-based approach has: no deployment hassles for either the initial running of an app or any subsequent updates.

   My problem with this is that we are now doing more and more of our coding in Javascript and ActionScript, and less and less in Python. I've done a lot of that, and I much prefer Python to Javascript.

I agree, but we do so because Javascript is in all modern browsers, and most folks have browser installed. This is key. For example, we work with the US Coast Guard a lot -- it takes them literally a year (or more) to get permission to install a new piece of software on their systems. By then there's an update available, and the permission process starts over -- if we can deliver an app that run inside the browser they already have, we can avoid all that.

    That's cool - something like wxPython app wouldn't be very useful then in that situation. There are lots of places that disallow Flash and/or Javascript, so you have to code to what your target can use.

By the way, my proposed talk is about embedding a web-app (html+Javascript+server) in a wxPython app to make it like a desktop -- the reverse path of yours!

    Sounds interesting. Let's just hope that we both get accepted, and that they don't schedule us in the same time slot! :wink:

-- Ed Leafe

Not that it matters, but I plan to be at Pycon 2009. Hopefully you guys will get your proposals accepted and I'll be able to attend them both. The problem with Pycon is that there are usually a bunch of really good talks going on at the same time though...

Mike

Ed Leafe wrote:

There is also a major addition to the framework: the ability to deploy Dabo applications as true web apps.

From your description, it sounds like you're building client-server networked apps, not web apps.

I think most people define a "web app" as one where the client runs in the browser. Flash and JAVA can kind of confuse things, but if you need a wxPython client, I don't think it's a web app.

If you are using REST to communicate with the server, than it's a "web service"

Or I may have misunderstood your description.

    Don't worry, it's not uncommon when talking about an entirely new approach.

    Your comment about having to run in a browser to be a web app is probably the sticking point. The point about a browser is that it grabs the most recent version of a page from a server and displays it to the user. Dabo does the same thing. It doesn't require you to install anything once the browser is installed; we're creating a similar app that will likewise not require anything but that one app to run any Dabo web app.

    Kevin Dangoor gave an excellent keynote at PyWorks last month, in which he talked about the evolution of web apps from simple read-only HTML to forms to basic Javascript to AJAX to complex JS frameworks. His point was that over time the trend is clearly toward richer and richer client experiences (hence the rise of Flash).

    My problem with this is that we are now doing more and more of our coding in Javascript and ActionScript, and less and less in Python. I've done a lot of that, and I much prefer Python to Javascript. So that's why I started working on the reverse approach: take a rich desktop UI and add to it all of the things that make web apps so attractive: zero deployment, seamless updates and server-side control of logic and data access.

I've had something like this stewing in the back of my mind for several years now. Those of you who have been around here for a very long time may remember me talking about the "wxPython Runtime Environment" where one aspect of it was a web deployment feature. (I also had the concept of Python eggs in there a few years before those showed up from PJE.) At one point there was a couple people working on some aspects of the wxPRE idea and documented it on the wiki, but it didn't get very far before they disappeared. It's good to see some motion in this idea-space again.

···

On Dec 10, 2008, at 2:17 PM, Christopher Barker wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Mike Driscoll wrote:

Ed Leafe wrote:

However, and this is purely a semantic argument -- a "web app" is an
app that runs in t "standard" browser, which means HTML at the core
-- or, if you want to stretch the definition a bit, an app that runs
in standard browser plugin (flash, etc).

I don't know what to call what you've done -- it's your chance to
coin a new term!

    I guess up until now a 'web app' and a 'browser app' were one and
the same. I'm trying to broaden that. Also, most browser activities
are with web pages, not necessarily web apps.

    At the same time, I don't think that there will be a wholesale
dropping of HTML and Javascript anytime in the foreseeable future no
matter what "cool new thing" came along. It's simply too ubiquitous,
and it would be silly to try to change that. That's not what I want
to do. I was kind of inspired by Adobe Air, which creates rich client
apps using Flash but without the browser. This would be rich client
apps in Python/wxPython, and also without the browser.

Does it use http to communicate with the server?

    Yes.

> The point about a browser is that it grabs

the most recent version of a page from a server and displays it to
the user.

well, yes -- but the other point is that it's a standard piece of
software, with multiple implementations (incompatible , of course!),
and that it uses primarily html. Those are key features of what
folks expect when they say "the web" or "web app".

    Probably true. I'm not too hung up on the terminology; I simply
wanted to marry all the advantages of a rich client UI like the one
that wxPython give us with the advantages that a browser-based
approach has: no deployment hassles for either the initial running of
an app or any subsequent updates.

   My problem with this is that we are now doing more and more of
our coding in Javascript and ActionScript, and less and less in
Python. I've done a lot of that, and I much prefer Python to
Javascript.

I agree, but we do so because Javascript is in all modern browsers,
and most folks have browser installed. This is key. For example, we
work with the US Coast Guard a lot -- it takes them literally a year
(or more) to get permission to install a new piece of software on
their systems. By then there's an update available, and the
permission process starts over -- if we can deliver an app that run
inside the browser they already have, we can avoid all that.

    That's cool - something like wxPython app wouldn't be very useful
then in that situation. There are lots of places that disallow Flash
and/or Javascript, so you have to code to what your target can use.

By the way, my proposed talk is about embedding a web-app
(html+Javascript+server) in a wxPython app to make it like a
desktop -- the reverse path of yours!

    Sounds interesting. Let's just hope that we both get accepted,
and that they don't schedule us in the same time slot! :wink:

-- Ed Leafe

Not that it matters, but I plan to be at Pycon 2009. Hopefully you
guys will get your proposals accepted and I'll be able to attend them
both. The problem with Pycon is that there are usually a bunch of
really good talks going on at the same time though...

I won't be able to attend (I'm a continent away). It would be cool if
they had videos available of all the talks. Then you would be able to
see the talks you've missed (you won't be able to participate, but it is
the next best thing), and me too. Many people would be willing to buy
those videos I guess.

···

On Dec 10, 2008, at 4:09 PM, Christopher Barker wrote:

Why not see about organizing a PyCon Argentina? Or a PyCon South America?

  ... just a thought! It would give me a great excuse to finally travel there!

-- Ed Leafe

···

On Dec 11, 2008, at 10:04 AM, Ricardo Aráoz wrote:

Not that it matters, but I plan to be at Pycon 2009. Hopefully you
guys will get your proposals accepted and I'll be able to attend them
both. The problem with Pycon is that there are usually a bunch of
really good talks going on at the same time though...

I won't be able to attend (I'm a continent away). It would be cool if
they had videos available of all the talks. Then you would be able to
see the talks you've missed (you won't be able to participate, but it is
the next best thing), and me too. Many people would be willing to buy
those videos I guess.

Why not PyCon Australia

Only way I could attend

Joe

Ed Leafe wrote:

···

On Dec 11, 2008, at 10:04 AM, Ricardo Aráoz wrote:

Not that it matters, but I plan to be at Pycon 2009. Hopefully you
guys will get your proposals accepted and I'll be able to attend them
both. The problem with Pycon is that there are usually a bunch of
really good talks going on at the same time though...

I won't be able to attend (I'm a continent away). It would be cool if
they had videos available of all the talks. Then you would be able to
see the talks you've missed (you won't be able to participate, but it is
the next best thing), and me too. Many people would be willing to buy
those videos I guess.

    Why not see about organizing a PyCon Argentina? Or a PyCon South America?

    ... just a thought! It would give me a great excuse to finally travel there!

-- Ed Leafe

_______________________________________________
wxpython-users mailing list
wxpython-users@lists.wxwidgets.org
http://lists.wxwidgets.org/mailman/listinfo/wxpython-users

Ricardo Aráoz wrote:

Mike Driscoll wrote:
  

Ed Leafe wrote:
    

However, and this is purely a semantic argument -- a "web app" is an
app that runs in t "standard" browser, which means HTML at the core
-- or, if you want to stretch the definition a bit, an app that runs
in standard browser plugin (flash, etc).

I don't know what to call what you've done -- it's your chance to
coin a new term!
        

    I guess up until now a 'web app' and a 'browser app' were one and
the same. I'm trying to broaden that. Also, most browser activities
are with web pages, not necessarily web apps.

    At the same time, I don't think that there will be a wholesale
dropping of HTML and Javascript anytime in the foreseeable future no
matter what "cool new thing" came along. It's simply too ubiquitous,
and it would be silly to try to change that. That's not what I want
to do. I was kind of inspired by Adobe Air, which creates rich client
apps using Flash but without the browser. This would be rich client
apps in Python/wxPython, and also without the browser.

Does it use http to communicate with the server?
        

    Yes.

The point about a browser is that it grabs
the most recent version of a page from a server and displays it to
the user.
          

well, yes -- but the other point is that it's a standard piece of
software, with multiple implementations (incompatible , of course!),
and that it uses primarily html. Those are key features of what
folks expect when they say "the web" or "web app".
        

    Probably true. I'm not too hung up on the terminology; I simply
wanted to marry all the advantages of a rich client UI like the one
that wxPython give us with the advantages that a browser-based
approach has: no deployment hassles for either the initial running of
an app or any subsequent updates.

   My problem with this is that we are now doing more and more of
our coding in Javascript and ActionScript, and less and less in
Python. I've done a lot of that, and I much prefer Python to
Javascript.
          

I agree, but we do so because Javascript is in all modern browsers,
and most folks have browser installed. This is key. For example, we
work with the US Coast Guard a lot -- it takes them literally a year
(or more) to get permission to install a new piece of software on
their systems. By then there's an update available, and the
permission process starts over -- if we can deliver an app that run
inside the browser they already have, we can avoid all that.
        

    That's cool - something like wxPython app wouldn't be very useful
then in that situation. There are lots of places that disallow Flash
and/or Javascript, so you have to code to what your target can use.

By the way, my proposed talk is about embedding a web-app
(html+Javascript+server) in a wxPython app to make it like a
desktop -- the reverse path of yours!
        

    Sounds interesting. Let's just hope that we both get accepted,
and that they don't schedule us in the same time slot! :wink:

-- Ed Leafe

Not that it matters, but I plan to be at Pycon 2009. Hopefully you
guys will get your proposals accepted and I'll be able to attend them
both. The problem with Pycon is that there are usually a bunch of
really good talks going on at the same time though...
    
I won't be able to attend (I'm a continent away). It would be cool if
they had videos available of all the talks. Then you would be able to
see the talks you've missed (you won't be able to participate, but it is
the next best thing), and me too. Many people would be willing to buy
those videos I guess.

Last year they recorded all or most of the talks. They were supposed to go up somewhere...but I never heard where. There are some on youtube though. From what I've heard, they plan on recording them again this year as long as the speakers are ok with it.

Mike

···

On Dec 10, 2008, at 4:09 PM, Christopher Barker wrote:

http://www.youtube.com/pycon08

-- Ed Leafe

···

On Dec 12, 2008, at 8:08 AM, Mike Driscoll wrote:

Last year they recorded all or most of the talks. They were supposed to go up somewhere...but I never heard where. There are some on youtube though. From what I've heard, they plan on recording them again this year as long as the speakers are ok with it.

Ed Leafe wrote:

···

On Dec 11, 2008, at 10:04 AM, Ricardo Aráoz wrote:

Not that it matters, but I plan to be at Pycon 2009. Hopefully you
guys will get your proposals accepted and I'll be able to attend them
both. The problem with Pycon is that there are usually a bunch of
really good talks going on at the same time though...

I won't be able to attend (I'm a continent away). It would be cool if
they had videos available of all the talks. Then you would be able to
see the talks you've missed (you won't be able to participate, but it is
the next best thing), and me too. Many people would be willing to buy
those videos I guess.

    Why not see about organizing a PyCon Argentina? Or a PyCon South
America?

    ... just a thought! It would give me a great excuse to finally
travel there!

-- Ed Leafe

Actually PyAr is right now organizing PyCon Argentina 2009. I think the
wiki is at http://trac.usla.org.ar/proyectos/pycon-ar (haven't checked
it yet). So I look forward to meeting you here :slight_smile:

I'm interested, but it forces me to login before I can see anything about it, and doesn't give me the option to register.

  How do I access the site? I'd really like to learn more to see if it would be possible for me to participate in this conference.

-- Ed Leafe

···

On Dec 16, 2008, at 9:42 AM, Ricardo Aráoz wrote:

Actually PyAr is right now organizing PyCon Argentina 2009. I think the
wiki is at http://trac.usla.org.ar/proyectos/pycon-ar (haven't checked
it yet). So I look forward to meeting you here :slight_smile:

Ed Leafe wrote:

···

On Dec 16, 2008, at 9:42 AM, Ricardo Aráoz wrote:

Actually PyAr is right now organizing PyCon Argentina 2009. I think the
wiki is at http://trac.usla.org.ar/proyectos/pycon-ar (haven't checked
it yet). So I look forward to meeting you here :slight_smile:

    I'm interested, but it forces me to login before I can see anything about it, and doesn't give me the option to register.

Upper-right, "register" link.

Paul