Hannes, sincerely thank you very much for answering in spite of the panic that's taken place here.
Being away on business I missed the entire buzz. My first reaction was to keep it with Francis and steer clear of the soi-disant svg- developers owners and group moderators. Yet the caused confusion yielded in some valuable contributions (in my opinion). Thanks Doug for clarification that sometimes one may feel offended when no offense was intended. Sincerely Hannes, I did not have the smallest intention to bash your work! I just realized the vast amount of work you've put into your simulation, it did hurt me to have to stand by and see it happening, or rather it was like an instant recall of a familiar pain! Moreover, you didn't ask for comments off-list. Obviously some folks on this group want to ignore the fact that svg is hardly ever present on the web. Despite the fact that usable plugin(s) have been around for years now. One has to stay off this list if he takes the freedom of expression that bloating svg at a snail's pace wouldn't be ultima ratio in this situation? On the other hand, it is not clear how much svg takes place at intranet level? There's definitely some svg use at large scale company intranets. I've been caught up in a number of that kind. The big question is, if these projects would have any chance if they would be planned today? I do have my doubts. Today, you'll have a very hard time to get roll-out clearance for a plugin that bypasses maintenanced parsers, script interpreters and c-s communication... There are too many expensive kludges to get around the svg-dhtml dom isolation issues... And, finally, you might end up with server-side pdf generation for printouts calling the entire svg stuff into question. After all, servers load isn't that crucial at the intranet level. To get back to the simulation sample, I've been truly curious about some platform decision insights. Now, that svg tempts people into bottom-up design, actually implies the simplicity to knock a demo together using notepad. There's no question that real world projects will have top-down design and require roi tables. The bike simulation looked somewhat like a real world example. Also one may notice that a real web application would require a lot of extra plumbing taking care of different client browser/viewer implementations. Again, considering the enormous number of man-hours you've put into your project, I also think this svg-developers group is jointly responsible for a type of svg engineering that's not going to work for a svg-mass-phenomenon we all would desperately like to spread out to real world. Besides the academic world, one has to pay the prize for an (hand crafted) ajax (awkward named hype) application. For high responsive webapps with far reach and server load importance handcrafted ajax solutions are perfectly valid. For svg's spread in the first place it's not very helpful. If I remember rightly Corel's svg js-lib thing was a disaster. Whenever it suits you want applications to generate all this complex stuff against various profiles and implementations, right? IMHO, those who are willing to bring in more and more 'complexibility' into svg are inimical to svg's initial spread. I'm not sure who's the solid svg community that asked w3c to bloat svg forever. Pretty much impertinent to serve someone with a deportation if one doesn't agree in this matter. Ultimately, svg should convince the mass (hence it follows browser *vendors*) by it's characteristic features! There shouldn't be any need to mix up svg with browser preferences, open source zealots, or market monopoly hue and cry. Ok, I'll stop here. 'One shouldn't demand too much of the ordinary web user, but expect resistance if a web user feels helpless in the face of a web page.' Hannes, you've got me wrong here, wasn't against *your* application. It's a general skepticism that svg widgets replacing common controls and old familiar gui elements do suffer from major usability deficits. I want that eg. scrollbars or picklists *operate* and show up identical throughout the system. Well blow me, I guess it's definitely a must for the occasional app. I feel no desire to offend other people, but I have no compunction not to complain about the unfortunate w3c-adobe alliance concerning xml graphics. Together they just made sure that investing into svg is comparable to gambling. And yes, there's been no essential svg progress at adobe since M. Bierman left the building, nevertheless it took years of stagnation until others took the risk of implementing the complex spec. Even now there're still chances left that adobe might strike back given their influence and implementation lead concerning svg. I for one do not want encourage the use and development of svg to them again and again. That's all. Every single comment is welcome, off-list of course, due to the new policy;-) And, please take it easy, Life *is* too short! None of us owns the philosopher's stone. PS: 1,2 million renesis preview video downloads aren't a bad number! Hey, there's more than this so called community;-) --- In [email protected], "Hannes Fleischer" <[EMAIL PROTECTED]> wrote: > paul, you answered the wrong question! the right question would > be: "would you do in svg again", not "why did you do in svg"? > > sometimes, things start small, and keep growing ever after. while svg > was perfectly suited in the beginning, your question might be > justified by now. > > to be honest, sometime around january i was seriously considering > porting everything to another platform, but for several very good > reasons i choose not to, at least not now. > > i would like to know, where are those "more productive platforms"? > should be viewable on the web, should'nt ask too much of the user > when it comes to installing the plugin or runtime, .... > > finally, let me assure you, i will not leave people "helpless in the > face of a web page". my project does not force anybody to use a fancy > svg navigation. it does not keep you from going anywhere because of > being too complex. > > the complexity is contained in the subject itself and not in the > implementation. my application gives experts (or to be experts) the > opportunity to deal with their matters in a very straighforward way. > people use my application because it gives them the complexity they > want in a very simplistic way (as measured by comparable software)!!!! > > best regards, > > Hannes > > > > > --- In [email protected], "welkerpaul" <[EMAIL PROTECTED]> > wrote: > > --- In [email protected], "Hannes Fleischer" > > <[EMAIL PROTECTED]> wrote: > > ... > > Hannes, > > up front, I feel sorry for you adding the following comment to > your > > post. I got strong counters from Alastair concerning a similar > > topic, so please don't feel hold cheap if people's thoughts differ > > on the matter. > > Your svg bike simulation is a very impressive showcase for a svg > > expenditure. In fact, it's one of these hefty tome applications > > using the svg applet as a runtime engine. > > I'm eager to learn why you did choose svg for your bike simulation. > > On the one hand there're more productive application platforms to > > choose from, on the other hand taking the hassle of building a > > javascripted webapp from ground would take it for granted having > > reasonable reach for the app? > > I'm curious to know, most of the talk in this group is about > > scripting svg. I'm even more curios about svg's roadmap, so the > > following words are only indirectly related to your simulation: > > We know that browsers aren't built as a platform engine for > > webapplications. The w3c graphics group was/is about evolving a > > platform for helping out web developers with a platform for > > arbitrary (web-)apps? I mean arbitrary in a literal sense since svg > > will foster one missing almost any common sense, usability and > > design rules the web typifies to some degree these days? To put it > > in slightly exaggerated terms: Is a 'svg+javascript enabled web' > > the ultimate way to 'break the web' employing w3c web standards? > > No, this would be basically a distortion of facts, obviously > talking > > a lot of nonsense. > > Anyway, it's adobe that bought in the flash-app svg aspects into w3c > > ($). The adobe svg viewer still rules svg today. But the viewer was > > built as adobes pendant to macromedias flash player. It's a damned > > runtime engine, greedy and slow, bears it own script realization > and > > server communication, and hardly talks to it's surrounding dom > > implementation. And please, don't tell me they couldn't do any > > better. At least for the major browser it's straightforward and > > ordinary difficult to implement inline svg though binary behaviors. > > > > So please, someone tell me that svg was evolved to add better > > graphics to a web page rather than replacing the web page with a > > bulky proprietary application. Is svg going to end as the flash for > > students and the poor? Will we need a svg-spoofed-window popup > > blocker in future? > > One shouldn't demand too much of the ordinary web user, but expect > > resistance if a web user feels helpless in the face of a web page. > > On the contrary, svg needs to convince the public to call for svg > > enabled browsers!? > > > > curios cheers > > Paul ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
