Re: [LHA-misc] Line parsing routine
Status: Beta
Brought to you by:
ncherry
From: Jay H. <jh...@fa...> - 2000-12-01 16:09:28
|
At 10:43 AM 12/1/00 -0500, you wrote: >Paul Fox wrote: >> >> > to note that if we needed compression on the fly that the file size >> > would hinder things. Because of my networking background I tend to think >> > that compression is best left to storage. If we compress data over a >> >> in general you're right -- but if the data is, say, the memory image >> of the device in question, then it clearly can't be stored compressed. >> and equally clearly, it could be quite large -- so if you wanted to >> request a full memory dump of your 32KB refrigerator controller, you >> might want the ability to do on-the-fly compression. another example >> might be wanting to speed up the download of a large background image >> to a dedicated controller -- perhaps for the touchscreen on that same >> refrigerator. :-) > >The internet 'frig is coming, the internet 'frig is coming .... :-) Just as long as I don't get emails at 5pm every day that go: 2gal Milk 1dz Eggs, Large Less than 1 bowl of Dutch Chocolate ice cream The meatloaf from monday is growing in mass - you may want to check it. >You make a very good point and with the recommendation that Jay made (S Records) >it's still possible to create a mode where the data sent is compressed and >sent as a line of X characters with addressing and CRC. This is of course an >extended mode. So there is a possible solution to a problem I hadn't thought >of. > >> but clearly compression is at odds with ascii data representation. i say >> do the simple things first, and leave the hooks in the protocol so you >> can add what's necessary later. (e.g. perhaps an optional "encoding=foo" >> parameter.) > >Simple for now but we can extend as necessary. Leaving the option open >is always a wise idea. We may never use it but we also haven't locked >ourselves into anything too restrictive. > >Now where the heck to docuemnt this! I'mm thinking to include a "standard download" in the agent document something like this: DOWNLOAD type="start" addr="..." type="firmware|lir|voice|..." encode="..." name="..." persistent="NO|yes" autoload="NO|yes" DOWNLOAD type="data" srec="..." DOWNLOAD type="done" (it now gets loaded to the device) DOWNLOAD type="abort" It is up to the agent to look at the address and decide if it can take the download and what to do with it. Probably also add to the initial start request of the data should be persistent and auto-downloaded. Some things like firmware you have to watch flash cycles but other things come up dumb... This could also be used to load new programs on a TINI... On that document... Text or Word (95/98)? Embedded Pics (Viso) or Line Art? Jay >-- >Linux Home Automation Neil Cherry nc...@ho... >http://members.home.net/ncherry (Text only) >http://meltingpot.fortunecity.com/lightsey/52 (Graphics) >http://linuxha.sourceforge.net/ (SourceForge) >_______________________________________________ >http://lists.sourceforge.net/mailman/listinfo/linuxha-misc >To unsubscribe, send "unsubscribe Linuxha-misc" >in the body of a message to Lin...@li... |