Reply to thread

Message

Re: AW: Re: MP2, plugins, and multiple clients.

Could be the case. Thats why I recommended testing here. One thing that may help (but only implement that if really really needed) is to create larger bitmaps containing multiple images to reduce the amount of small files sent of the NW (there is a term for that, ehhhmm... ah: packedgfx is what you guys use I guess).

Sure, but SSD / HDD will be permanent and still be there when a new session is started and could hold more data.

Yes that is what we should do, but no, that was not what I meant ;-)

What you describe is similar to the pre-fetch algorithms in windows. It caches the data you probably need in the near future. A pre-fetch might really be easily implemented, as you would generally start getting thumbs with the ones visible and then get the ones further away from the current view-point, probably preferring forward direction over backward.

What I meant is making the caching mechanism transparent to the code. Similar as stream handlers can be stacked, one stream delivering to the next stream. This way you can start developing without caching and then insert a caching algorithm when needed. So neither the code fetching the thumbs from the server, nor the code using the thumbs should be dependant on any caching functionality and the interface between them should be fixed. You can then insert the cache if it consumes the same interface that it produces (as in my sample pseudo-code).

Regards
Marc

<blockquote data-quote="mbuzina" data-source="post: 654611" data-attributes="member: 12382">Re: AW: Re: MP2, plugins, and multiple clients.Could be the case. Thats why I recommended testing here. One thing that may help (but only implement that if really really needed) is to create larger bitmaps containing multiple images to reduce the amount of small files sent of the NW (there is a term for that, ehhhmm... ah: packedgfx is what you guys use I guess).Sure, but SSD / HDD will be permanent and still be there when a new session is started and could hold more data.Yes that is what we should do, but no, that was not what I meant ;-)What you describe is similar to the pre-fetch algorithms in windows. It caches the data you probably need in the near future. A pre-fetch might really be easily implemented, as you would generally start getting thumbs with the ones visible and then get the ones further away from the current view-point, probably preferring forward direction over backward.What I meant is making the caching mechanism transparent to the code. Similar as stream handlers can be stacked, one stream delivering to the next stream. This way you can start developing without caching and then insert a caching algorithm when needed. So neither the code fetching the thumbs from the server, nor the code using the thumbs should be dependant on any caching functionality and the interface between them should be fixed. You can then insert the cache if it consumes the same interface that it produces (as in my sample pseudo-code).RegardsMarc</blockquote>

[QUOTE="mbuzina, post: 654611, member: 12382"] [b]Re: AW: Re: MP2, plugins, and multiple clients.[/b] Could be the case. Thats why I recommended testing here. One thing that may help (but only implement that if really really needed) is to create larger bitmaps containing multiple images to reduce the amount of small files sent of the NW (there is a term for that, ehhhmm... ah: packedgfx is what you guys use I guess). Sure, but SSD / HDD will be permanent and still be there when a new session is started and could hold more data. Yes that is what we should do, but no, that was not what I meant ;-) What you describe is similar to the pre-fetch algorithms in windows. It caches the data you probably need in the near future. A pre-fetch might really be easily implemented, as you would generally start getting thumbs with the ones visible and then get the ones further away from the current view-point, probably preferring forward direction over backward. What I meant is making the caching mechanism transparent to the code. Similar as stream handlers can be stacked, one stream delivering to the next stream. This way you can start developing without caching and then insert a caching algorithm when needed. So neither the code fetching the thumbs from the server, nor the code using the thumbs should be dependant on any caching functionality and the interface between them should be fixed. You can then insert the cache if it consumes the same interface that it produces (as in my sample pseudo-code). Regards Marc [/QUOTE]