Business Developers was ->Re: IBM Gives RPG Devotees Their Own Café

[Aaron Bartell <aaronbartell@xxxxxxxxx>]

Thanks for reminding us to continue this conversation Alan.  (Nathan, 
sorry if my challenge sounded like I thought we shouldn't pursue it 
because after re-reading it I could see how it might)

With that said I have some rough thoughts I have been wanting to pass by 
those that have done a lot in the web world.  I get the feeling that the 
web technologies (i.e. HTML+JavaScript+CSS+Remoting) is constantly 
trying to get back to what we have had with the 5250 data stream for 
years - that being fairly easy server side deployed code that hides 
complexity. 

My question is this: When will we ever reach the point of personnel 
being business developers again vs. needing to be a techgeek+business 
developer?

We might reach the business developer status again with open 
specification technology, but I think it will take A LOT longer than if 
we were to just go with proprietary routes again.  The big players are 
starting to realize this more and more with Silverlight, Flex and 
JavaFX, but they all are in their infancy as they haven't had time to be 
molded by patterns developed over time.  I am not saying completely 
proprietary is the way to go, but one could make a very proprietary 
technology that was also feature rich in integrating with other 
technologies and platforms, and you would only ever go "outside the box" 
if your current proprietary technology stack wasn't meeting your needs 
(i.e. this has been the story of green screen's demise IMO)

Thoughts?

Aaron Bartell
http://mowyourlawn.com


steelville wrote:
>  >>   >Another good point. But why is the web _nothing_ like that? Can't 
> we as web application developers do something about that? Don't we 
> control the design of our applications?
>
>  >>Nathan, I realize that you are trying to look at this from different 
> angles and play a little bit of devils advocate, but now you are 
> changing the playing field.  The comments being made are based on what 
> is available *today* and not what we *could* create someday down the road.
> ----------
> The comments made were based on that but as a web developer he's 
> researching the possibilities, which is *always* a good exercise for 
> creative programmers. ;) I say let's have more! After all, there are 
> some like Aaron here who have been good examples of this! :-) Hey, need 
> I mention the pioneering days of midrange-L??
>
> So it provoked my thinking. The yahoo mail now looks a suspiciously more 
> like a regular email client nowadays. A web-based email client opens up 
> more possibilities than just reading email. To gain any ground at all, 
> in my point of view, especially from a tech guy's perspective, it would 
> have to do everything email does now but more than that!
>
> Today even Google and yahoo web mail presentations are way behind email 
> clients in this, like Aaron said.
>
> The biggest drawback for basing anything like this on the web is the 
> absolute minimum requirement for the constant unbroken connection over 
> the Net. That is a major hurdle for a web-based client too.
>
> But that's not insurmountable either, with __1__a combination of email 
> interface, __2__some stand-alone pieces that can sit on the client, 
> __3__the use of client storage, __4__adaptability to both rich and thin 
> clients, __5__the use of interplay between the client storage and web 
> service CQ at intervals to check connections __6__and to check for more 
> incoming activity, and so on.
>
> --Alan
>
>