A small (personal) fix to The Plan would look like: - Quickly remove glib dependency, since it is commonly agreed. - Don't touch python code; just don't compile tn5250-python.c in the makefile? Someone can remove it if he wants, I won't remark :) - Don't touch S/Lang. I would flavour to keep it since it seems quite simple and just deactivate the enhanced support. Just adding a line for this is not that bad :) But I will hardly be able to add some quite of support of the protocol to lib5250 (to my knowledge). We can talk about this if you want. I can submit patches to remove some of the glib dependency on HEAD or someone else can do it, has long that the work is not duplicated uselessly. Marc-Antoine Ruel > -----Message d'origine----- > DeÂ: linux5250-bounces@xxxxxxxxxxxx [mailto:linux5250- > bounces@xxxxxxxxxxxx] De la part de James Rich > EnvoyÃÂ: 25 fÃvrier, 2005 17:09 > ÃÂ: tn5250 > ObjetÂ: [LINUX5250] roadmap > > The recent talk about cvs branches has me thinking about the "roadmap". > As pointed out in > http://archive.midrange.com/linux5250/199910/msg00034.html Jason Felice > suggested some time ago how he thinks tn5250 development should go. I > think since then things have changed (or not changed) and warrant a new > roadmap. So here are my ideas for changing the roadmap that Jason > suggested: > > 1. tn5250 version 1.0 should be focused on complete support of the 5250 > protocol and not much else. > > 2. Forget about gnome and kde integration for now. That is definately a > post-1.0 goal. > > 3. Likewise other language bindings should be post 1.0. > > 4. Complete documentation is a must. > > 5. A "reference" terminal that implements all the 5250 features that we > add to lib5250 as part of (1) above. Whether that terminal is cursesterm > or slangterm or activex or x5250 it doesn't matter. But we need one that > is complete. > > I think that tn5250 1.0 should focus on just one thing: supporting > everything the iSeries can throw at us. Other things like key mapping, > desktop integration, language bindings can wait until after. > > So here is what I'm willing to work on to get us there: > > 1. completing support in lib5250 for the entire 5250 protocol > 2. documentation (hopefully the HOWTO I wrote will help here) > > Since I have a strong interest in x5250 that is the terminal I will spend > the most time perfecting. Not to say that I'm unwilling to work on the > other terminals, just that since we have a way for the terminal to > indicate to lib5250 that it doesn't support all features, I'm happy to > leave them at that and focus on x5250. In my opinion, x5250, winterm, and > activex are the only terminals with the capabilities to use the enhanced > 5250 protocol anyway. > > What does everyone else think? > > James Rich
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.