Re: SVG1.2 and web applications

Fred P. wrote:
> Let say, that I was pretty pleased by DSM Event handlers
> http://www.w3.org/TR/2003/WD-SVG12-20030715/#dsm
> and similar UI control, anything that can simplify my scripting life is 
> welcome! =)

Have you used other similar approaches such as XForms actions? You seem to be 
saying that you'd the DSM or something declarative in a non-mobile environment 
(which is what it has thus far been mostly targetted at), can you describe how 
you think it'd make writing SVG apps better in general? We're very interested in 
feedback :)

> Network interface would be nice (simple like Perl FTP, IRC, HTTP CPAN 
> modules)
> 
> Maybe a Socket Interface to TCP/UDP sockets?

If we provided the minimum TCP/UDP interface and users had to build their own 
protocols on top of it, would you be satisfied? Have you given thought to the 
security model? If it worked along the lines of "for each connection to a new 
address:port combination, prompt the user to accept the connection (with the 
option to accept connections to that address:port combination every time)" would 
it be a problem? Not secure enough? Too obtrusive?

> Someone proposed a "push" technology solution for constant broadcasting
> of networked clients working on a same SVG document:
> 
>  1) A type some stuff,   while B and C watch the changes real-time
>  2) B delete some stuff, while A and C watch the changes real-time
>  3) C edit some stuff,   while A and B watch the changes real-time
> 
> Think of this as an advanced chat or netmeeting SVG application on the web
> for collaborative team work exchange remotely located.

Well if you had a complete socket interface, you could get an event whenever 
data arrives. On top of that you could then implement the system you describe on 
top of it.

As for a generic way to do that without scripting, the W3C is soon to hold a 
workshop on binary infosets. It is naturally one of the topics.

> if I want to resize the 'SVG applet', I would need to recalculate all 
> scrollbars,
> position of buttons, width of background, shadow and stuff like that 
> instead of writting
> something that depends on the size and location of a window, like I 
> would do in C/C++ or Java.

RCC should make it eas(y|ier) to handle such events in the context of a specific 
widget which you implement.

> These are my current concerns:
> 
> - Having easy-to-program widget and especially extend them for 
> look-and-feel (color, style, size).

If someone were to provide an RCC library of widgets, would that address your 
needs or do you need them to be native.

> For instance, nobody have to program normal CGI forms widget behaviour 
> in XHTML,
> it just works with simple <input> tags definition.

Yes, but they're ugly ;)

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Engineer, Expway        http://expway.fr/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488

Received on Monday, 18 August 2003 10:27:01 UTC