Fwd: Re: tigert's mockups and HTML

[Lars Hallberg]

Tuomas Kuosmanen wrote:

>On Wed, 2004-09-22 at 13:08 +0200, Lars Hallberg wrote:
>
>  
>
>>But we do design fore the futer her to, Todays higend system don't realy 
>>have problem with a HTML rendering. Tomorrow anything less than a video 
>>notifikation might make the desktop look pale and outdated! XEMBED keeps 
>>the door to the futer open!
>>    
>>
>
>07:39 <@jimmac> :)
>07:40 <@jimmac> "why does my modem blink so freaked out for the past ten
>                minutes?"
>07:40 <@jimmac> "wassssssuuuuuupp???"
>07:40 <@jimmac> oh, a message arrived!
>
>;)
>  
>
Must admit i was limeted enuf to only think on cases where the app and 
the notification server was on the same machine :-) But simply limiting 
it to 'simple text' notifications when they not might be good enuf?

Hovever, XEMBED only embeds apps? We for shore not only whant to embed a 
HTML-renderer, but also suply the HTML for it to render! For stuff like 
video, we whant to suply the URI, don't think sending the actual video 
stream over the notifikation protocol is a good idé :-)

But this demand some extension to XEMBED? To tell the embeded app what 
to view? To comunicate a set of text fields is probably enuff.

Probably, mimetype and data/uri is a better level of abstraction. Wher 
the notification server can tell (and probably be asked in adwance) if 
it can suport a given mimetype. That way allot of detail can be left to 
the implementation, and if apps is required to be able to fallback on 
simple text notificatens, it's a way for lowend system to force 
'lightwight' notificatons.

If the notification service can report whether a given URI is availible 
(localy) that might alow video notification remotly, if the actual video 
is avalible localy.

Some kind of 'basedir' URI would be good for this. IE, a way to say 
'locate foo.mpg for app bar acording to the basedir spec'.

/LaH