| Subject | Re: [IBO] Kylix |
|---|---|
| Author | Jason Wharton |
| Post date | 2001-05-07T14:36:02Z |
Dalton,
Actually, I don't have an official list of things accomplished or that I
hope to accomplish.
Here's a rough sketch of what the major items are. There are actually a fair
amount of smaller things I know I am going to forget until I make a focused
effort to compile them all.
Horizontal dataset refinement is the technical term for the most major
feature I have added in. What this means is that you specify a base query
which actually results in a significantly large dataset. (Like over 100K
rows) Then, as you issue commands to the dataset to navigate among these
records IBO will automatically refine itself to pull in those records of
interest only. Internally this affected the buffers quite a bit. Before I
could always assume that the buffer had the BOF position and that it
wouldn't grow in that direction. Now my buffers have to be aware that they
may need to pull in records at the beginning or the end or both if you have
done a locate out in the middle somewhere. As long as you have proper
indexes all dataset navigation commands should complete within 1 or two
seconds. This makes using things like InfoPower with the TDataset stuff
totally rock. Incremental searching is amazingly fast, for example.
TDataset is handling these changes in dataset buffering architecture but
unfortunately the naive IBO controls like TIB_Grid were much less tolerable
to these changes. I am having to make significant alterations to TIB_Grid to
support this more flexible buffering architecture. This is what is actually
holding up the release of the general components to the masses.
The next major feature is the ability to maintain client/side filtering of
records. It is also possible to change the filter logic and refresh without
having to refresh the dataset from the server. There is now a
RefreshFilteredRows method that will recalculate the filtered status of all
records in the buffer and adjust the dataset accordingly as if a refresh had
been done. This has been coupled with the ability to show cached deleted
records or not as well.
CachedUpdates has received a lot of improvements in how it integrates with
the server centric nature of IBO. These two opposed models are able to be
harmonized quite a bit and IBO 4 takes it to a much more accurate and
efficient level of integration.
I have greatly enhanced the session level background processing mechanisms.
Instead of using a timer on the session to fuel things like automatic
Transaction OAT management I have designed and implemented an architecture
that hooks you right into the IDLE cpu message notifications from windows.
This produces much more fluid and efficient handling of background tasks
that IBO relies upon happening.
In addition to the changes above I have tied in other components to this new
architecture. The IB_Events component and all components which descend from
the TIB_Process class are hooked into the sessions ability to fuel passive
processes via idle cpu cycles. Thus, TTimer components should not be
necessary anymore with minimal setup. For the IB_Events, this also takes
care of the synchronization of the event notifications. Part of the
session's new architecture includes a WakeUp notification system designed
just for this.
I have developed a base class for writing NT Services with IBO. It is
possible to write a simple service easy enough but to do it correctly there
are some difficult points to iron out. It involved doing some things that
took quite a bit of head scratching to get just right. The new session
architecture for passive processing fits right into this as the service
application executes in a passive manner.
I have developed some components that are used to provide a top to bottom
full(fuzzy) text searching solution. It isn't 100% server based as the index
needs to be maintained by a client process but it is possible to use it from
any client, whether IBO or not. You just have to have an IBO application
running somewhere to maintain the index. All of the triggers to do it are
build automatically. It also does logging of searches too, including
internal server statistics for performance metering.
I plan to also complete a simple replication module that will follow the
same patter as the above search index maintaing components. There are some
significant similarities in the process of maintain index tables and
replicated tables. This is something I want to finish this week. I already
have replication stuff in place, I just haven't made it generic for release.
I am working on making IBO tolerate broken connections much better. Along
with this, I am making it so that you can actually allow a transparent
disconnect from the connection and when activity starts up again reconnect
transparently. There will be timing configurations similar to the
transaction OAT handling mechanisms. One example of how this could be useful
is an application goes idle for 15 minutes and there are no active
transactions. The app will simply let the connection handle go by
disconnecting it. When the user returns they go to use their application and
they are notified that the application is resuming itself. After it performs
the reconnection it will reallocate all the statement handles and flag all
queries to reprepare themselves.
I have split up IBO into separate packages for better support of runtime
packages. I also have specific designtime packages too. There will be four
major runtime packages. Core components, tools/utility components, visual
components and forms/dialogs. One designtime package will bring these into
the IDE and this will be the native stuff. For the TDataset stuff it will
need the core runtime and there will be a runtime just for the TDataset
based classes. There will also be a separate designtime only package to
bring these into the IDE. I will also have separate packages for the IBOWeb
internet stuff, replication components and the full text components.
Geoff introduced the usage of interfaces to make it easier to integrate
controls into TIB_Grid and other external processing, like mask handling,
into core IBO classes without requiring that the necessary files be compiled
and hard linked to IBO. This will allow Geoff to maintain his components in
separate packages from the IBO components. It will also allow me to have
more "stable" releases and still allow 3rd party people to integrate with
IBO better.
I added in the ability to support macro processing in the SQL and other
properties of the statement/dataset/script. Some of this work actually
leaked into 3.6 because I needed it there. Pretend you never saw it there.
<g> A number of other things that were to be 4 only leaked as well. I don't
remember what all they were.
I'm sure there is more but I'm itching to get back to coding... <g>
Helen, please make a note of this email. This will help with our release
notes.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
Actually, I don't have an official list of things accomplished or that I
hope to accomplish.
Here's a rough sketch of what the major items are. There are actually a fair
amount of smaller things I know I am going to forget until I make a focused
effort to compile them all.
Horizontal dataset refinement is the technical term for the most major
feature I have added in. What this means is that you specify a base query
which actually results in a significantly large dataset. (Like over 100K
rows) Then, as you issue commands to the dataset to navigate among these
records IBO will automatically refine itself to pull in those records of
interest only. Internally this affected the buffers quite a bit. Before I
could always assume that the buffer had the BOF position and that it
wouldn't grow in that direction. Now my buffers have to be aware that they
may need to pull in records at the beginning or the end or both if you have
done a locate out in the middle somewhere. As long as you have proper
indexes all dataset navigation commands should complete within 1 or two
seconds. This makes using things like InfoPower with the TDataset stuff
totally rock. Incremental searching is amazingly fast, for example.
TDataset is handling these changes in dataset buffering architecture but
unfortunately the naive IBO controls like TIB_Grid were much less tolerable
to these changes. I am having to make significant alterations to TIB_Grid to
support this more flexible buffering architecture. This is what is actually
holding up the release of the general components to the masses.
The next major feature is the ability to maintain client/side filtering of
records. It is also possible to change the filter logic and refresh without
having to refresh the dataset from the server. There is now a
RefreshFilteredRows method that will recalculate the filtered status of all
records in the buffer and adjust the dataset accordingly as if a refresh had
been done. This has been coupled with the ability to show cached deleted
records or not as well.
CachedUpdates has received a lot of improvements in how it integrates with
the server centric nature of IBO. These two opposed models are able to be
harmonized quite a bit and IBO 4 takes it to a much more accurate and
efficient level of integration.
I have greatly enhanced the session level background processing mechanisms.
Instead of using a timer on the session to fuel things like automatic
Transaction OAT management I have designed and implemented an architecture
that hooks you right into the IDLE cpu message notifications from windows.
This produces much more fluid and efficient handling of background tasks
that IBO relies upon happening.
In addition to the changes above I have tied in other components to this new
architecture. The IB_Events component and all components which descend from
the TIB_Process class are hooked into the sessions ability to fuel passive
processes via idle cpu cycles. Thus, TTimer components should not be
necessary anymore with minimal setup. For the IB_Events, this also takes
care of the synchronization of the event notifications. Part of the
session's new architecture includes a WakeUp notification system designed
just for this.
I have developed a base class for writing NT Services with IBO. It is
possible to write a simple service easy enough but to do it correctly there
are some difficult points to iron out. It involved doing some things that
took quite a bit of head scratching to get just right. The new session
architecture for passive processing fits right into this as the service
application executes in a passive manner.
I have developed some components that are used to provide a top to bottom
full(fuzzy) text searching solution. It isn't 100% server based as the index
needs to be maintained by a client process but it is possible to use it from
any client, whether IBO or not. You just have to have an IBO application
running somewhere to maintain the index. All of the triggers to do it are
build automatically. It also does logging of searches too, including
internal server statistics for performance metering.
I plan to also complete a simple replication module that will follow the
same patter as the above search index maintaing components. There are some
significant similarities in the process of maintain index tables and
replicated tables. This is something I want to finish this week. I already
have replication stuff in place, I just haven't made it generic for release.
I am working on making IBO tolerate broken connections much better. Along
with this, I am making it so that you can actually allow a transparent
disconnect from the connection and when activity starts up again reconnect
transparently. There will be timing configurations similar to the
transaction OAT handling mechanisms. One example of how this could be useful
is an application goes idle for 15 minutes and there are no active
transactions. The app will simply let the connection handle go by
disconnecting it. When the user returns they go to use their application and
they are notified that the application is resuming itself. After it performs
the reconnection it will reallocate all the statement handles and flag all
queries to reprepare themselves.
I have split up IBO into separate packages for better support of runtime
packages. I also have specific designtime packages too. There will be four
major runtime packages. Core components, tools/utility components, visual
components and forms/dialogs. One designtime package will bring these into
the IDE and this will be the native stuff. For the TDataset stuff it will
need the core runtime and there will be a runtime just for the TDataset
based classes. There will also be a separate designtime only package to
bring these into the IDE. I will also have separate packages for the IBOWeb
internet stuff, replication components and the full text components.
Geoff introduced the usage of interfaces to make it easier to integrate
controls into TIB_Grid and other external processing, like mask handling,
into core IBO classes without requiring that the necessary files be compiled
and hard linked to IBO. This will allow Geoff to maintain his components in
separate packages from the IBO components. It will also allow me to have
more "stable" releases and still allow 3rd party people to integrate with
IBO better.
I added in the ability to support macro processing in the SQL and other
properties of the statement/dataset/script. Some of this work actually
leaked into 3.6 because I needed it there. Pretend you never saw it there.
<g> A number of other things that were to be 4 only leaked as well. I don't
remember what all they were.
I'm sure there is more but I'm itching to get back to coding... <g>
Helen, please make a note of this email. This will help with our release
notes.
Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "Dalton Calford" <dcalford@...>
To: <IBObjects@yahoogroups.com>
Sent: Monday, May 07, 2001 6:48 AM
Subject: Re: [IBO] Kylix
> Hi Jason,
>
> I have seen you refer to IBO 4, but have not seen what you hope to have in
> it. Do you have a .plan or .readme that details where you hope IB04 will
be
> when you release it?
>
> best regards
>
> Dalton
>
> On Monday 07 May 2001 09:15, you wrote:
> > Ken,
> >
> > Sorry I didn't answer this sooner.
> > The port to Kylix will be completed soon after IBO 4 is completed.
> > That is going to put it around June or July sometime.
> > I hope to have a BETA much sooner than that so you can all at least be
> > playing, prototyping, etc. with it.
> >
> > It is time I started assembling a list of who all wants the IBO Kylix
BETA
> > when it is ready.
> >
> > PS. I already am working on it and continue to work on it. I'm not just
> > waiting to finish IBO 4 before I start on it.
> >
> > Jason Wharton
> > CPS - Mesa AZ
> > http://www.ibobjects.com
> >
> >
> > ----- Original Message -----
> > From: "Kenneth Wilcox" <kwilcox@...>
> > To: <IBObjects@yahoogroups.com>
> > Sent: Wednesday, May 02, 2001 7:39 AM
> > Subject: [IBO] Kylix
> >
> > > var
> > > date: TDateTime;
> > > begin
> > > if not (IBOPrortedToKylix) then
> > > date := GetReleaseDateInformation
> > > else
> > > date := LastUploadDate;
> > >
> > > ShowMessage('The value of date is: ' + DateTimeToStr(date));
> > > end;
> > >
> > > What's the value of date?
> > >
> > > Sorry, my native language is PASCAL.
> > >
> > > Ken
> > >
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>