| Index > Scribe > LDAP News | |
|---|---|
| Author/Date | LDAP News |
| Cyco 02/05/2002 6:21am | Don't ask me why, but to me that's sad news...
Bigger chance for you to generate cashflow is great, and to get to that point you are going to have to make it more "buisness oriented", that is fully understandable, but for me as the regular home user who will have no use whatsoever for any groupware or such, and use i.Scribe for the sole purpose of speed, size and compactness, that does not sound like good news. i.Scribe beats alot of excellent e-mail clients out there despite it's compactness in features, that's why I continue to come back to i.Scribe even after trying other, but this new direction will probably take the edge of i.Scribe, making it more generic among all the other clients despite all it's new wonderful functions. Please tell me I'm wrong... |
| fReT 02/05/2002 9:18am | I'm working on ways of intergrating functionality through plugins, so that raw vanilla Scribe can stay the same.
What I'm talking about is scalability, which doesn't directly relate to size. So instead of having one fixed method of reading and writing objects to disk, I want to have an interface for many methods. As an example... I'm aware that flexibility often brings with it greater overheads in transactions and that is what I'm hinting at. If Scribe is 30% bigger and 20% slower but it can do 10 new things then that might be a worthy trade off. The software has grown from 200k at v1.00 to over 500k at v1.63, so I've been trading size for features all along. I guess the trend just continues on. I've thought about what it would take to reign in the size, but it just seems to always come back to features = size. And I want a certain minimum level of features. Which requires a minimum level in size and speed. And I don't think I've reached that yet. But in concesion to the people that want a minimal client I'll try make the product modular so that you can make up the bits you want and have a bit of both worlds. Speed, size and features can all be traded off with each other depending on the components you put together. Worst comes to worst I can always maintain 2 code bases for a while and keep people happy that way. |
| Reply | |