Fwd: Re: tigert's mockups and HTML
spam at micropp.se
Wed Sep 22 16:12:53 EEST 2004
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
>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
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'.
More information about the xdg