RE: roadmap -- LINUX5250

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