[platform-text-dev] Support for record-oriented document styles

[David Dykstal <2sirius@xxxxxxxxxxx>]

Kai and others --

I'm working with a team that (among other things) has ported an editor
into the eclipse environment.  This editor is a high-function,
general-purpose editor that offers support for source files that are
"record oriented" as opposed to "stream oriented".  Record oriented
files are those typically found on IBM zSeries and iSeries systems,
and may be found on other systems as well.  They are characterized by
(sometimes) having fixed record lengths, sequence number fields, and
possibly other "metadata" fields in the source records themselves. 

We've found that we had to diverge from the standard document model
and provide our own text widgets in order to support the features that
users of these systems have come to expect: sequence number handling,
automatic change flagging, DBCS support with alternate (non-Unicode)
rendering, block editing, column based editing, hidden lines,
selecting and editing beyond the "end" of a line, etc.  

However, by diverging from that model, we find that we have to play
"feature catch up" with the text framework -- essentially rewriting
new features that platform text introduces.  Not good.  We'd love to
get out of that business and concentrate on providing enhancements to
our basic editing engine and parsers.  We're thinking we'd like to
port some of our features in to the standard text framework so that we
take advantage of that framework and get rid of some of this
duplication.  We'd like to do this sometime after eclipse 3.0, so now
is the time to start thinking about this.

We'd be willing to live as a contributor to the text framework and
supply patches to be reviewed by the text team.  In return we would
need the occasional pointer / design discussion to take place in the
mailing list.  The goal would be to end up with eclipse document model
extensions and a widget set that would be of general use for files of
this type regardless of the system of origin.  We would then, of
course, exploit this model for our own use, but we fully expect others
could make use of that model as well.

Does this sound feasible?  What's the best way to start?

-- Dave Dykstal
2sirius@xxxxxxxxxxx
david_dykstal@xxxxxxxxxx