Hi Marcus, I understand what you mean and agree with you.
The reason I want it optional is for use cases like often sent small pieces of data, emoticons are an example. I believe an optional "cache" attribute would add no significant complexity (especially if the recieving client MAY ignore it) but still be important for some low-bandwidth use. Another problem is... that you sometimes cannot maintain sessions. With the current spec, how do you implement sending many times the same data to a contact you don't get presence (e.g. no subscription) and that doesn't implement (or currently use) chatstates. Is the answer: Ok, we have no session, we send it each time again? Pavel On Fri, 25 Jul 2008 12:46:06 +0200 Marcus Lundblad <[EMAIL PROTECTED]> wrote: > ons 2008-07-23 klockan 03:52 +0200 skrev Pavel Simerda: > > Hello, > > > > I have some suggestions for XEP-0231 (Data Element). > > > > Right now, as the example shows: > > > > <message from='[EMAIL PROTECTED]/castle' > > to='[EMAIL PROTECTED]' > > type='groupchat'> > > <body>Yet here's a spot.</body> > > <html xmlns='http://jabber.org/protocol/xhtml-im'> > > <body xmlns='http://www.w3.org/1999/xhtml'> > > <p> > > Yet here's a spot. > > <img alt='A spot' > > > > src='cid:[email protected]'/> > > </p> > > </body> > > </html> > > <data xmlns='urn:xmpp:tmp:data-element' > > alt='A spot' > > cid='[EMAIL PROTECTED]' > > type='image/png'> > > iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP > > C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA > > AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J > > REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq > > ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 > > vr4MkhoXe0rZigAAAABJRU5ErkJggg== > > </data> > > </message> > > > > Note: in this particular example the data is very short, this may > > not be the case in real world where people tend to ignore the size > > of data they send. > > > > We send data once for every session (and omit for subsequent > > messages). > > > > This has two important implications: > > > > 1) The other entity may or may not cache it for the session and > > reuse it. That is good. > > > > 2) If an entity keeps the data for a longer time (e.g. for weeks > > or even permanently), this cache will never be used. As the sending > > entity always resends the data for a new session. > > > > What I propose is: > > > > * By default the sending entity would not send the data. It would > > merely reference it by its cid url. > > * Let the recieving client follow "3.4 Retrieving Uncached Media > > Data" if the data is not cached (no real change, this is already > > being done). > > * Reserve the possibility of sending the data immediately with the > > message for the *specific* case that the sending client actually > > knows the recieving party cannot have the data cached (e.g. the > > data was never sent before). This behavior should be considered > > optional. > > > > I further propose we add some informational section about generation > > of CIDs. Although it's specified elsewhere, I believe this XEP will > > be very useful and will be referenced from many future XEPs (and > > maybe improved as well - possibly some server caching etc). I think > > the informational section could suggest UUIDs generated by hashing > > the actual content. > > > > Another thing that could be considered... is to add some sort of > > caching hint attribute that would suggest how long its reasonable to > > cache a particular resource. Maybe we could borrow from HTTP Cookies > > but allow (suggest) the clients to have some mechanisms for > > limiting the time, size and number of cached objects. > > > > There are many possibilities, I will just describe one of them. > > > > cache="no" > > - no reason for caching the file will not be used again > > cache="session" > > - we suggest the recieving party only caches for this > > particular session > > cache="12" > > - we suggest caching for twelve days from the last use of this cid > > (!) > > - for every use (recieved reference) the recieving client should > > reset the date we count from > > cache="unlimited" > > - we suggest the client picks the longest time it allows (it could > > possibly cache some small pieces of data permanenty) > > > > Of course, the client MAY ignore the caching hit. In this case it > > SHOULD NOT cache at all. > > > > If the cache attribute is not specified, we should decide on a > > reasonable default value ('session' or '1' day both seem good to > > me). > > > I have written an implementation of the current XEP use-case 3.1 > (in-band images) in libpurple (Pidgin). > Currently it always includes the data the first time it is sent in a > session. But the implementation will also request the data using > use-case 3.4 if it hasn't cached it. Currently caching is only done > in-memory within a session (really a chat conversation). > So this implementation would still work if another client would use > something along the above proposal. > > Though I'm not sure if it's worth the extra complexity, since the > recommended max size is 8 kB. Also the emoticons I have used are > generally quite small, often around 1 kB. > > Maybe we could add a clause that says the sender "MAY include the > data" the first time it is used. This way it could be optional to > include the data. In some special cases a client can choose to not > include the data if it knows the receiver might have it cached. > > In other cases it would probably not make sense to cache data, such as > when providing a preview for an image file transfer. > > //Marcus > > > > Cheers, > > Pavel > > > > -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
