- From: NARUSE, Yui <naruse@airemix.jp>
- Date: Wed, 21 Mar 2012 17:41:41 +0900
2012/3/21 Jonas Sicking <jonas at sicking.cc>: > I'm pretty sure there is consensus for supporting UTF8. UTF8 is > stateful though can be made not stateful by not consuming all > characters and instead forcing the caller to keep the state (in the > form of unconsumed text). Your use of the word "stateful" involves misunderstanding. Usually the word "stateful encoding" means that the encoding keeps a state between characters, not bytes. What you mean is usually expressed by the word "multibyte". UTF-8 is multibyte encoding, and it needs to keep a state on streaming. > So I would rephrase your 3 options above as: > > 1) Create an API which forces consumers to do state handling. Probably > leading to people creating wrappers which essentially implement option > 3 > 2) Don't support streaming > 3) Have encoder/decoder objects which hold state > > I personally don't think 1 is a good option since it's basically the > same as 3 but just with libraries doing some of the work. We might as > well do that work so that libraries aren't needed. > > This leaves us with 2 or 3. So the question is if we should support > streaming or not. I suspect doing so would be worth it. I think it should provide non streaming API. And if there are concreate use case, provide streaming API as another one. -- NARUSE, Yui ?<naruse at airemix.jp>
Received on Wednesday, 21 March 2012 01:41:41 UTC