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

[Kai-Uwe Maetzel <kai-uwe_maetzel@xxxxxxxxxx>]

Dave,

The work you have done sounds interesting.
I understand
your point of the catch-up game. This
is never fun.

In a good solution the text component
of the Eclipse SDK
enables a separate plug-in to provide
the support for "record oriented"
editors. I think what you call "an
extension to the eclipse document model"
is thought as such an enablement. Taking
the approach of a separate plug-in
has several  advantages:
- It allows you to make progress and
to mature your component without being
  locked into the "stable
API" rule too early. 
- It allows us to carefully select and
adopt the pieces of functionality that should
  become part of the text component.
- It does not couple this endeavor to
the post 3.0 goals to be defined by the PMC.

I think it would be helpful if we better
understand what your requirements are and
in which respect your editor model can
be considered  an extension or special case
of our editor model. Best would be if
we could see one of your editors in action.
Having a better understanding of your
requirements allows us to better assess
the feasibility and the extent of the
work. The best time to start with that is post 3.0.

Thanks for your offer, Kai

David Dykstal <2sirius@xxxxxxxxxxx>
Sent by: platform-text-dev-admin@xxxxxxxxxxx

04/13/2004 12:46 AM

Please respond to
platform-text-dev@xxxxxxxxxxx

To	platform-text-dev@xxxxxxxxxxx
cc
Subject	[platform-text-dev] Support for record-oriented document styles

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

_______________________________________________
platform-text-dev mailing list
platform-text-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-text-dev