[REBOL] Re: rebol-framework: information
From: robert:muench:robertmuench at: 29-Dec-2002 14:24
> -----Original Message-----
> From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
> On Behalf Of Petr Krenzelok
> Sent: Saturday, December 28, 2002 5:26 PM
> To: [rebol-list--rebol--com]
> Subject: [REBOL] Re: rebol-framework: information
> We will see ... that's one of things I didn't liked - very few
> datatypes. The question is, how many datatypes is enough?
Hi, maybe datatype isn't the right word. What you actualy specify by
providing a "datatype" for an attribute is its default behaviour. So for
example: date! Will add a function to the label of the data field that,
if clicked, will bring up a date-requester, further the entered date
will be transformed to Rebol format before being saved in the database.
So, datatypes are more to specify base-functionality.
> Should there be ability to define own datatype via some kind of
control
> function? (e.g. to use parse rules to define some custom datatypes)
I didn't thought about this yet. But it's possible.
> hmm, what does it mean? Does it mean you used RFM to define app data
> structures? I just hope you don't use RFM itself to enter the
> data? I am not sure it is good aproach, but I will have to see, if
sexy app
> offers enough comfort for end user to work with.
Yes, with RFM you don't have the typical "application to track bugs"
approach. Instead you say: "I add bug-report BOT to RFM" and than you
have this functionality within the RFM application (GUI). With this
approach I want to include/integrate some of the "naked objects" idea.
> So far I prefer strong tool to define data dictionaries of BOs, share
them
> across internet etc. and let the UI part be completly separated task
...
I don't think this makes sense. To create a good GUI is like a "black
art" and it needs a good feeling for useability from the programmer. For
example, I like programming but I don't like to spend to much time with
the GUI. I know it's very important but other can do it better. IMO
there shouldn't be to many different GUI/useablility approaches
used/mixed in an application. That's why I would like RFM to build an
appropriate GUI from the BOT definition.
Since Cyphre created a first good GUI, we were able to merge our
development stuff very fast without to many interface problems. We will
see... At the moment the approach looks very promising.
> cool. I just hope you implement incremental update functionality as
> Cerebrus does. Works nicely .... user does not need to download whole
> new executable, but just differences, which are XORed agains current
> executable, or something like that ....
Why not! IIRC the Cerebrus patch function was posted, right? If so, we
will use it. The hardest part will be to update changes to the
data-model...
> hmm, we will see how it scales .... I mean - storage mechanism.
I made some basic tests so these are far from any real life numbers but
I think up to 10.000 records should be possible with the current
approach. I further look into LDAP for a server side storage mechanism
and Berkley DB (with DLL interface) for a local storage mechanism.
> Do you think that RFM could be used to rewrite IOS reblets into?
> Would there be already any benefit? I miss ability of cross reblet
apis in IOS.
That's what I'm missing too and that's why I started to work on RFM. My
goal is to move the data from the current IOS reblets into RFM and use
RFM as the single application that supports integration/assocication
between every piece of data.
This will need a multi-user storage concept, that supports parallel
changing of data and later merging of it. Will follow after the
standalone version works OK. Robert