[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
> 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
> 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
> 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
> 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