Seeing the previous mail of Ueda-san, the ROM size isuue is not the discussing
point. And I hardly understand your comparison of the code size to VxWorks or
Jet Send.
The value of 30k itself has not determined well enough. Even if it is true,
does 30k cover real symmetric structure for the equipment and some upper layer
i/f capability which Thin Protocol might cover to put on DPP command/data set
?
I am slightly sensitive to talk about just ROM size based on someone's
imagination or illusion which has not well identfied the functionality.
Jet Send's code size is not worth for comparing or discussing transport layer.
"Consumer" product is very sensitive to cost of code size, but it also depends
on the benefit of "consumer". In my experience, the first EOS system had 64kB
total ROM 10 years ago, but it was successful in the market for the reason of
integration of automatic and manual tuning capability with simple user
interface. JetSend might lead successful product in consumer market regardless
of its code size. But this is not the discussiong point in PWG-C.
I may be wrong, or misunderstood your point due to my lack of knowledge, but
the questioning the ROM size to Ueda-san sounds very strange after checking the
back log you attatched.
At 14:11 98/02/15 +0900, you wrote:
> Dear Toru san,
>
> One point.
> I think 30k is good size even for cheap consumer devices.
> This size is smaller than typical VxWorks implementation, and it
> may be smaller than JetSend.
>
> So please give us information how big your DPP ROM size is expected to.
>
$B<DED!!?.Hf8E(J
$B#N#o#b#u#h#i#k#o!!#S#h#i#n#o#d#a(J
B$B%7%9%F%`3+H/ItItD9(J
General$B!!(JManager
BJ Printing System Development Division
B$B5!4o5;=Q3+H/%;%s%?!<I{=jD9(J
Assistant Senior General Manager
BJ Printing System Technology$B!!(JDevelopment Center
$B#C#a#n#o#n!!#I#n#c!%(J