Re: Spolsky's requests for Web Applications

I don't know what to think! All these are really nice stuff... :)))

However, I was talking in more radical terms:
E.g. not to re-use the Mozilla components as libraries for the 
interoperation of other stuff
(e.g. in a way similar to COM)... I was (implying) to rebuild the whole 
application _ON TOP_
of the mozilla components.... so instead of making the browser a 
component of the application
you make the application a component of the browser...

But: not all the functionality that you need is, probably, supported by 
the device neutral mozilla APIs, you probably don't want to re-write the 
whole application, and it's probably only a good
solution if you have all the time in the world and want to see if it 
could work...

...So, after all, what you say seems more reasonable :))

...but it could be done...



Andrew Mayo wrote:

>Hmm, well that is a good point but the interfaces that the outer, business logic requires are so simple that the API set would need to expose that level of simplicity; and the complication here is event handling.
>
>In the VB6/IE6 world the browser is embedded as an ActiveX control. Therefore COM is the communication layer, and as such it handles both the 'API' end of things and event handling. Event handling is the Achilles Heel of the old API model; it requires kludgy hacks to make it work and many programming languages one might choose as the outer business layer will have real trouble handling events.
>
>Essentially though, if it *were* possible to use bits of Mozilla, you'd be asking from the outer layer to
>
>(a) load (i.e navigate) a page of HTML and display it in a context provided by the calling application
>(b) call Javascript functions against that page
>(c) Navigate through the DOM of the page within the controlling language
>(d) Receive events from the DOM of the loaded page
>(e) Print the page
>(f) Render the page to a device context supplied by the controlling program
>
>(this last option is a crucial one for specialised printing - for example, I use this in IE6 (it's called 'DrawToDC') in order to print labels on printers where the standard Windows driver causes the printout to appear 'upside down' when the user is facing the printer. This is stupid but the only way to work around it is to render to DC using a world transform to flip the whole thing 180 degrees.
>
>Now, all of the above requirements are met very nicely by VB6/IE6 and COM. 
>
>Suppose we said for a moment, 'well, let's use Java as the controlling language instead'.
>
>(I'm making this assumption because the controlling language needs to be, IMHO)
>
>(a) compilable
>(b) strongly-typed in order to guard against developer error
>(c) strongly object-oriented
>(d) support structured exception handling
>(e) support garbage collection automatically
>(f) have a reasonable IDE for developers
>(g) platform-neutral
>
>and there aren't a lot of other choices currently that meet all these requirements - in fact, I can't think of ANY! - I know Java isn't precisely open source but it *is* free.
>
>Then I *guess* the browser as a reusable component would become a Java Bean.
>
>So in this instance I guess we can call into an API set like XPCOM (though events I am not *quite* sure about, but I'm sure this is doable).
>
>Now you might ask 'why not just use SWING' if you're going to use Java, but I'd like to hope you can see why not (apart from the 24M of memory PER RUNNING INSTANCE that Swing uses - Java doesn't reuse loaded class memory across instances for 'security reasons' (sigh!).
>
>In any case, Swing doesn't handle the printing issues. And content authoring would have to be done inside the IDE... no, it doesn't fly!.
>
>So my dream is increasingly looking like Mozilla/Firefox as a Java Bean, I think, plus the enhancements (standard SVG and contenteditable) PLUS a Java class library that exposes the DOM (I think this *might* already exist).
>
>Now someone is going to want Python or Perl support and that's fine if they can solve the event problem and (at least in Perl's case, the weird syntax that the DOM is going to have to be mapped to - I mean, how do you do 'document.all.item("something")' in Perl?.
>
>Or maybe C# but I really think Java's the way to go here. 
>
>Now I have a platform-neutral, reasonably thin client layer - because my UI stuff, 90% of the bulk, is all done in the browser. So my business code & the Java runtime are quite slim. Then, of course, using SOAP etc, I could entirely remote the whole UI layer from the controlling application if I really wanted to.
>
>The final part of the equation is a good Open Source RDBMS, but that's solved. PostgreSQL will do nicely, thanks (not MySQL, that's a cardfile!).
>
>At this point I have the development platform for the 21st century. A rich UI, but able to be partitioned any way I like. Clean separation of business logic from presentation logic. Built-in printing and report handling. Ah, utopia!.
>
>What do you think?
>
>
>
>-----Original Message-----
>From: Michael Pediaditakis [mailto:mp49@kent.ac.uk]
>Sent: 21 June 2004 13:25
>To: Andrew Mayo
>Cc: public-webapps-cdf-discuss@w3.org
>Subject: Re: Spolsky's requests for Web Applications
>
>
>On the same subject...
>
>Should the "browser" be seen as an application that enables the web content
>(XML, web appz and whatever) processing or should it be seen as a special
>application of a generic processing framework?
>
>Isn't the browser a special case of a web application?
>If this is the case, the whole  browser functionality would be fully 
>customizable and
>it would be easy to include it in any other application.
>
>In this sense, Mozilla is based on a well defined processing model 
>(XPCOM and all that)
>and thus, maybe, instead of trying to integrate Mozilla as a component, 
>it might be a better
>idea to re-use the bottom layers of Mozilla... 
>...and then functionality reuse should be quite straighforward...
>
>That are all theory of course... When I tried reusing some of Mozilla's 
>components, some years ago, I was so overwhelemed by the complexity of 
>the project that I simply abandomed the idea...
>...but now the situation seems much better... or not?
>
>Sorry, again, for generalizing specific discussions to visions for 
>generic XML processing :)))
>
>Michael Pediaditakis.
>
>Andrew Mayo wrote:
>
>  
>
>>To briefly comment on Joel's requirement for 'contenteditable' (as implemented in IE).
>>
>>This is a *crucial* feature for building a rich UI. Absolutely crucial. But the critical thing to understand about the browser in the context of richer UIs is that we don't have to just build purist web-based apps using the browser.
>>
>>Instead, we embed the browser as a component in a larger client-side application. This gives us a UI and rendering engine which - and this is equally important - can also PRINT things.
>>
>>I can't begin to tell you how many thousands of lines of code the browser saves you, as an embeddable component - I build large commercial systems under Windows using VB6 as the application language and embed IE6 as the UI and print engine. Via defined Javascript functions, the VB6 container interacts with the UI. This gives you a beautiful n-tier architecture that is also, potentially, OS neutral. (because, in theory, I could replace either VB or the browser without things changing).
>>
>>To do this properly in the Open Source world I *need* a browser that supports contenteditable. And vector graphics (VML is at least reasonably well supported in IE, for instance).
>>
>>Unfortunately the Mozilla/Firefox team appear to have given up trying to implement this feature as it is 'too hard'. Also progress on integrating SVG into the standard builds appears to be glacially slow.
>>
>>Joel, if you're listening. Or anyone who can help. PLEASE.... Joel, you've got kudos and perhaps some experiences as an ex-Microsoftee at organising teams. Can't you help bang some heads together to make this happen. I am desperate to see this materialise in a non-Microsoft platform!.
>>
>>
>> 
>>
>>    
>>
>
>  
>

Received on Monday, 21 June 2004 09:29:26 UTC