Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

rebol-framework: information

 [1/17] from: robert:muench:robertmuench at: 28-Dec-2002 16:33


Hi, I don't know if you are interested but I just want to give a short update what's going on with the rebol-framework (RFM) project: 1. I'm very happy that Cyphre has joined the project and is now doing the GUI stuff. The next release will have a complete new GUI that looks very sexy :-)) 2. The backend engine is growing and works quite stable. The handling of business-object-templates has been improved in that you have a lot of more "datatypes" that you can use when defining a BOT. 3. Cyphre and I are using the RFM to track bugs, ideas etc. for the project. The bug reporting has the same functionallity as bug-reporter on IOS. 4. I have bought the book from lazysoftware (thanks Petr to pointing me at it) about the "associative data model". We will see how much we can use from them ;-)) 5. I started to add functionality to the BOT definitons. Works quite well. This doesn't use any dialects (yet) but just uses Rebol code. So at the moment you still need some background information about how the RFM works internally. Should be changed over time. What have done so far? I implemented a NEWS BOT, that get's translated into HTML and than automatically published at my companies web-site. Very handy. You can see the result at: http://www.necony.de (news&mehr). Further I implemented a report function for the EFFORT/TIME BOT (that I use to track my time) that uses make-doc-pro to generate a HTML output. Not very pretty at the moment but it's a start. All this prooves that we are on the right track with RFM. Extensibility is really very easy. 6. I bougth the Command SDK and hopefully we will be able to release a single-user stand-alone-exe version of RFM. Should get a lot of people started much easier. 7. Development-Focus will be: Improving the GUI, working out a QUERY dialect and working out a RPORT dialect. If you have questions... Just ask them :-) Robert

 [2/17] from: petr:krenzelok:trz:cz at: 28-Dec-2002 17:26


Robert M. Muench wrote:
>Hi, I don't know if you are interested but I just want to give a short >update what's going on with the rebol-framework (RFM) project:
<<quoted lines omitted: 4>>
>business-object-templates has been improved in that you have a lot of >more "datatypes" that you can use when defining a BOT.
We will see ... that's one of things I didn't liked - very few datatypes. The question is, how many datatypes is enough? 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) .... will have to think about it ... and why? Because ... generally, coming from XBase world, there is e.g. date datatype, but XY needs to display such datatype. The question is - where to find the border? May it all depends upon how we store values into "database", as at some point, there could just one single datatype - string - with various parse rules to represent/translate into correct state ...
>3. Cyphre and I are using the RFM to track bugs, ideas etc. for the >project. The bug reporting has the same functionallity as bug-reporter >on IOS. >
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. 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 ...
>4. I have bought the book from lazysoftware (thanks Petr to pointing me >at it) about the "associative data model". We will see how much we can >use from them ;-)) >
mine is on its way too :-)
>6. I bougth the Command SDK and hopefully we will be able to release a >single-user stand-alone-exe version of RFM. Should get a lot of people >started much easier. >
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 ....
>7. Development-Focus will be: Improving the GUI, working out a QUERY >dialect and working out a RPORT dialect. >
hmm, we will see how it scales .... I mean - 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 ....
>If you have questions... Just ask them :-) Robert >
I did so :-) -pekr-

 [3/17] from: greggirwin:mindspring at: 28-Dec-2002 11:16


Hi Petr, << 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 .... >> I think they're actually a little smarter than that, but I could be wrong. I did a little XOR patching thing, and it does work well as long as the base EXE is the same that you encap against. Of course, mine is *very* simple so it's *not* very smart. :) -- Gregg

 [4/17] from: g:santilli:tiscalinet:it at: 29-Dec-2002 0:06


Hi Gregg, On Saturday, December 28, 2002, 7:16:46 PM, you wrote: GI> I think they're actually a little smarter than that, but I could be GI> wrong. We are not, actually. XOR works fine because the script is at the end of the encapped exe; also, it is very simple and does not require you to know anything about how Encap works (no breaking of the license). Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [5/17] from: greggirwin:mindspring at: 28-Dec-2002 19:41


Hi Gabriele, GI>> I think they're actually a little smarter than that, but I could be GI>> wrong. GS> We are not, actually. XOR works fine because the script is at the GS> end of the encapped exe; also, it is very simple and does not GS> require you to know anything about how Encap works (no breaking of GS> the license). Yes, that's why I like the approach. I just thought Graham had said that you were getting better results than I had with mine. Probably a faulty memory chip...in my head. :) -- Gregg

 [6/17] from: robert:muench:robertmuench at: 29-Dec-2002 14:24


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 4>>
> 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

 [7/17] from: petr:krenzelok:trz:cz at: 29-Dec-2002 17:50


> >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. >
yes, that is what I had in mind ...
>>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
<<quoted lines omitted: 8>>
>have this functionality within the RFM application (GUI). With this >approach I want to include/integrate some of the "naked objects" idea.
... which I personally find pretty messy aproach to UI .... myriads of separate windows - confusion. The more I work with users a database apps, the more I think MDI aproach is flawed, if does not serve special purpose. User enters data to one certain form at a time. Concepts like drag & drop in database apps are imo utopia and distract user from fast work - keyboard rules :-)
>>So far I prefer strong tool to define data dictionaries of BOs, share >>
<<quoted lines omitted: 8>>
>example, I like programming but I don't like to spend to much time with >the GUI.
noone does :-)
> 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. >
and what if others have complete different idea of how to represent data and their relations in UI? If RFM can't provide such functionality (separation), it kills its usability. What if someone will want to use it via web based forms e.g.? Anyway, I will have to wait and see, that's the best thing I can do right now ...
>>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
<<quoted lines omitted: 5>>
>RFM as the single application that supports integration/assocication >between every piece of data.
yes, but RFM already offers also GUI. So what will happen with IOS desktop and its reblets? -pekr-

 [8/17] from: robert:muench:robertmuench at: 29-Dec-2002 19:30


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 3>>
> Subject: [REBOL] Re: rebol-framework: information > yes, that is what I had in mind ...
:-)) fine!
> ... which I personally find pretty messy aproach to UI .... myriads of > separate windows - confusion.
I agree and should have to be more specific. I just like the basic concept of "naked objects" in that you see the same data object like the computer sees it. I don't like the GUI approach too. IMO a further good idea is to just offer the functions that make sense in an actual context (for objects of type X, for objects with association of type X and value of Y of Z... Etc.)
> User enters data to one certain form at a time. Concepts like > drag & drop in database apps are imo utopia and distract user > from fast work - keyboard rules :-)
I totally agree and be sure not to see a MDI application or any mouse-orgy action needed to do what you want.
> and what if others have complete different idea of how to represent
data
> and their relations in UI?
Well than write your own GUI for it. I hate learning trillions of GUIS, usage patterns etc. just because nobody follows a simple KISS rule. I just don't want to remember all the menues etc. The GUI must support useability and fast working experience... Fancy stuff can be added later.
> If RFM can't provide such functionality separation), it kills its
usability. We will see ;-)
> What if someone will want to use it via web based forms e.g.?
Web based forms? I really don't like Web-Applications. To me it's a completely missuse of a publishing concept. But we will see if and how a Web front-end can be added to RFM.
> Anyway, I will have to wait and see, that's the best thing I can do > right now ...
I hope it won't take to long for a new release....
> yes, but RFM already offers also GUI. So what will happen with IOS > desktop and its reblets?
The desktop will stay there but the Reblets... Well I won't need them anymore, at least the ones that do simple data stuff like contacts, bug-report, expert etc. My goal is to replaces these step-by-step with RFM and gain integration capabilties in return. Robert

 [9/17] from: ammon:addept:ws at: 29-Dec-2002 13:04


Two things... I agree, web based forms are a waste of space and time... And Where do I find RFM? Enjoy!! Ammon Johnson CIO of Addept ---------- (www.addept.ws) 435.616.2322 ---------- (ammon AT addept.ws)

 [10/17] from: ammon:addept:ws at: 29-Dec-2002 13:01


<snip> > >I don't think this makes sense. To create a good GUI is like a "black
<<quoted lines omitted: 3>>
> > > noone does :-)
</snip> Hey, I kinda like it and Cyphre says he loves it! ;-) Enjoy!! Ammon Johnson CIO of Addept ---------- (www.addept.ws) 435.616.2322 ---------- (ammon AT addept.ws)

 [11/17] from: robert:muench:robertmuench at: 30-Dec-2002 9:43


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 3>>
> Subject: [REBOL] Re: rebol-framework: information > Hey, I kinda like it and Cyphre says he loves it! ;-)
That's why I asked him to join the project ;-)) Robert

 [12/17] from: robert:muench:robertmuench at: 30-Dec-2002 9:43


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 3>>
> Subject: [REBOL] Re: rebol-framework: information > I agree, web based forms are a waste of space and time...
;-)
> Where do I find RFM?
There is a really early release on my homepage (http://www.robertmuench.de) and Cyphre and I currently work on a new release. We have to throw everything together and create a simple one-piece script first. But for a start take a look at my homepage. Robert

 [13/17] from: robert:muench:robertmuench at: 30-Dec-2002 15:27


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]] > On Behalf Of Ammon Johnson > Sent: Sunday, December 29, 2002 9:02 PM > To: [rebol-list--rebol--com] > Subject: [REBOL] Re: rebol-framework: information
Just want to let you know that I have created a RFM group @ AltME. So feel free to join the discussion there. The ML might not be the best place for RFM project related discussions. Robert

 [14/17] from: atruter:labyrinth:au at: 31-Dec-2002 17:16


Hi Robert, Read your doco and the conceptual basis looks pretty sound to me. I've also been working on an alternative to the traditional database approach and my thoughts, or emphasis, differ from yours. Since your doco got me thinking about other issues, I thought (hope!) I might return the favour by jotting down my thoughts on the subject. The "problem" I am attempting to solve is that the company I am trying to run receives and generates a lot of data in multiple formats (many of them not electronic). The formats include: digital documents (doc, pdf, etc) digital images (jpg, bmp, png, gif, tiff, etc) physical (books, photos, brochures, sales lists, invoices, etc) music (CD, tape, MP3, etc) video (DVD, VHS, AVI, etc) located and/or referenced in different "locations": email client browser (bookmarks and history) website(s) hard-drive removable media filing cabinet manilla folders notepad / sticky note which then depend upon disparate means of archival and retrieval: electronic file system databases sticky notes filing cabinets manilla folders someone's memory When we look at a source of data, eg a website or PDF, we spend some effort to: categorise what we are looking at understand the content remember where and when we found it Some of this "manual" processing may be recorded (in disparate places), most often it is committed to our (fallible) memory! I am trying to design a "system" that enables either the data itself (say in the case of "contacts") or a reference to the data (say in the case of PDF documents) to be stored without having to predefine an arbitrary data structure. The "system" should allow me to do things like: 1) show me the location of all data to do with embedded systems, sorted by what I have most recently looked at. [This should display an entry for each relevant source. Clicking on the entry should take me to the source (opening a PDF, logging onto a website, telling me the location of a physical folder, etc)] 2) generate a phone list based on my contacts 3) tell me which CD's contain optometric images in JPG format 4) Display my account details, including encrypted username / passwords / PINs 5) Tell me if the PDF on my HDD has been updated on the site I originally obtained it from, and if so, get it. My attitude to data capture is that it should be as easy as writing it on a piece of paper, because if it isn't then that's where it'll end up! The system should also infer as much as it can about the data. With that in mind I am trying to use a heuristic approach such that entering: Mr James Smith 28 Oakfield Street (03) 9876 1234 BH will store this record as key/value pairs (with each line being a value), but able to infer things about compound values (eg. while "Mr James Smith" is a name, the system should be able to work out gender, firstname and surname based on the value). In essence, the system would extend REBOL's knowledge of data types such that it knows what a value is and what it can do with that value. At this stage I'm thinking that REBOL can be used to determine the base datatype (eg. money, email, string, etc) pretty well, but the system will need to infer a bit more with some types (eg. is this string actually a phone number?) and offer logical choices and defaults once the datatype is determined (eg. You entered $12.50 which I know is money! and will default to "Price", but it could be "Amount", "Tax", Discount , etc). Depending upon the source of data, other attributes can be automatically deduced and stored. For example, a PDF file has a file name, location, create and modify dates, and with a little extra work the title, author and description (if any) can be extracted from the document itself. This approach, if achievable, does away with data structures and allows freeform queries to generate tabulated result sets (eg. "Show all invoice#, amounts" would know that amount is right justified and prompt to include a total summary). Anyway, I hope something in the above is of value [to someone] ;) Regards, Ashley

 [15/17] from: greggirwin:mindspring at: 31-Dec-2002 0:16


Hi Ashley, AT> This approach, if achievable, does away with data structures and allows AT> freeform queries to generate tabulated result sets (eg. "Show all invoice#, AT> amounts" would know that amount is right justified and prompt to include a AT> total summary). Of course it's achievable! Think dialects. -- Gregg

 [16/17] from: petr:krenzelok:trz:cz at: 31-Dec-2002 10:10


Ashley Truter wrote:
> Hi Robert, > Read your doco and the conceptual basis looks pretty sound to me. I've
<<quoted lines omitted: 5>>
> to run receives and generates a lot of data in multiple formats (many > of them not electronic).
Not electronic? Yes, there is plenty of such material around. You either find the way how to record info needed or knowledge of the material is nearly lost. You could also think of some kind of workflow engine, which would help you to keep track, what person (office) has certain files on their desk. It is all about processes. Being responsible for e-biz in our company, I came to the conclusion, that no single system is gonna to save you. Today, the world is about heterogenous systems, which you need to teach to communicate one to each other. WebServices anyone? :-) Typical example of broken chain of info flow inside our company: We use Lotus Notes as group-ware system here. Our user receives e.g. email concerning contract No. 1234. But all contract info is stored in SAP R3. So, currently, the email is lost (messages older than 180 days are moved to archive because of storage capacity problems). But - it should not be so! Later on we may need such email info as a decision point to some complaint of customer, etc etc. So you have to decide, what kind info is valuable to your company processess ....
> Some of this "manual" processing may be recorded (in disparate > places), most often it is committed to our (fallible) memory!
so it is nearly lost :-)
> I am trying to design a "system" that enables either the data itself > (say in the case of "contacts") or a reference to the data (say in the
<<quoted lines omitted: 5>>
> to the source (opening a PDF, logging onto a website, telling me the > location of a physical folder, etc)]
you could use full-text indexing, or even simpler aproach we use here to build our knowledge base. Just stick certain button on various company forms, which will allow your ppl to categorise stuff. We use it with our Lotus Notes system, and it simply works. You e.g. receive document, and assign it to "embedded systems" "kiosks" categories .... Later on, your knowledge base can be as simple as the tree of your terms ... so you click upon "embedded systems" and all relevant (recorded docs) are shown in the list
> 2) generate a phone list based on my contacts > 3) tell me which CD's contain optometric images in JPG format
both can be solved by what I describe above ....
> 4) Display my account details, including encrypted username / > passwords / PINs > 5) Tell me if the PDF on my HDD has been updated on the site I > originally obtained it from, and if so, get it.
well, this one would either need some kind of button on certain form to check it right away while you are at a form/doc, or you would have to run some kind of agent (background process/task), which would periodically check for doc updates. Some time ago I worked for Czech Amiga News server (http://amiga.czex.com ) and we build a small script, which periodically checked changes of list of sites and generated html doc out of it, so it saved us plenty of manual work ... quite easy done using Rebol :-)
> My attitude to data capture is that it should be as easy as writing it > on a piece of paper, because if it isn't then that's where it'll end
<<quoted lines omitted: 12>>
> thinking that REBOL can be used to determine the base datatype (eg. > money, email, string, etc)
I don't believe in Rebol datatypes usability, not in the way you require them to behave. Some language gurus will burn me here that following expression gives accureate info, but for me, it is of no value: ->> email? to-email "abc" == true If "abc" string can be pushed to represent email value, than I can't trust rebol datatype detection, or simply put it works in other way than I would need it. You seem to have pretty hing demands, so in your case, I would not try to mix rebol datatypes and your owns, but simply create whole datatypes detection from scratch by defining you own rules you expect your datatypes to meet ....
> pretty well, but the system will need to infer a bit more with some > types (eg. is this string actually a phone number?) and offer logical
<<quoted lines omitted: 6>>
> the title, author and description (if any) can be extracted from the > document itself.
you can stick objects e.g. to certain datatypes, which you can later on turn into GUI ... e.g. for detected file type: [ location: name: type: size: date: author: etc .... ]
> This approach, if achievable, does away with data structures and > allows freeform queries to generate tabulated result sets (eg. "Show > all invoice#, amounts" would know that amount is right justified and > prompt to include a total summary).
whatever :-) create some report engine, make it possible to being handled by dialect or other way .... but just don't forget about simplicity. Sometimes it seems to me, that Rebol is already an engine, which helps to directly construct what you need ... just don't spend too much time on high-level stuff (e.g. your report engine) - concentrate upon basic engine and rules of your system. Building good "ground" will reward you later .... -pekr-

 [17/17] from: robert::muench::robertmuench::de at: 31-Dec-2002 11:39


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]
<<quoted lines omitted: 4>>
> Read your doco and the conceptual basis looks pretty sound to > me.
Hi Ashley, thanks a lot. This is all still a very fast moving target as new ideas pop up daily etc. So still a lot of opportunities to make it better :-))
> The "problem" I am attempting to solve is that the company I > am trying to run receives and generates a lot of data in multiple
<<quoted lines omitted: 13>>
> manilla folders > notepad / sticky note
Oh yes, I know this (and I don't like this information fragmention, it's evil in daily work).
> which then depend upon disparate means of archival and retrieval: > electronic file system
<<quoted lines omitted: 11>>
> disparate places), most often it is committed to our > (fallible) memory!
That's the problem of information overload and much nastier: The problem that different people have a different understanding/interpretation of things. So IMO the effort to try to agree/implement a common, from all accepted concept of handling such things will never work! It can't work, because we think different... What looks logical to me, could be far from what you would understand to be logic.
> I am trying to design a "system" that enables either the data > itself (say in the case of "contacts") or a reference to the data (say > in the case of PDF documents) to be stored without having to predefine > an arbitrary data structure.
:-)) So far this sounds good...
> The "system" should allow me to do things like: > 1) show me the location of all data to do with embedded
<<quoted lines omitted: 3>>
> (opening a PDF, logging onto a website, telling me the location of a > physical folder, etc)]
Ok, I already have started to implement a "file!" datatype to be used for BOT. This will do some of the things you mentioned. BTW: I have exactly the same problem to solve ;-))
> 2) generate a phone list based on my contacts
That's pretty easy and could be done today with RFM. I'm using it at the moment to track my time and generate a report from this.
> 3) tell me which CD's contain optometric images in JPG format
Ok.
> 4) Display my account details, including encrypted username / > passwords / PINs
No problem too.
> 5) Tell me if the PDF on my HDD has been updated on the site > I originally obtained it from, and if so, get it.
This is more a file/directory differ. But could be done by building up a catalog entry with MD5 checksums.
> My attitude to data capture is that it should be as easy as > writing it on a piece of paper, because if it isn't then that's > where it'll end up!
Yes, totally agreed! That's what I want to have a GUI that is not fancy etc. It just should display me a simple data-form and support me with default values, good tab-sequence etc. as much as possible. The GUI should look the same as much as possible.
> The system should also infer as much as it can about the data.
;-)
> With that in mind I am trying to use a heuristic approach such that > entering:
<<quoted lines omitted: 5>>
> (eg. while "Mr James Smith" is a name, the system should be able to > work out gender, firstname and surname based on the value).
I see. I would do this a bit different. I would store the broken down data and have a heuristic function that will split the input BEFORE saving it. So this looks to me like an intelligen input-form.
> In essence, the system would extend REBOL's knowledge of data types > such that it knows what a value is and what it can > do with that value.
I don't know if we have to extend Rebol datasystem. Rebol is the base where we can build on. For example I have implemented a date! Datatype for RFM that has some intelligence like you mentioned. At the moment this is burried in the engine code. But this doesn't make sense... So I will shift this code into a customizeable datastructure that gets used at runtime in all needed places.
> Depending upon the source of data, other attributes can be > automatically deduced and stored. For example, a PDF file has a file > name, location, create and modify dates, and with a little extra work > the title, author and description (if any) can be extracted from the > document itself.
Yes, that's what I would expect to be added by the people. To stay with your example: I have this filecollection datatype. The user picks some files, next the filecollection BOT has some code to analyze the selected files. For some (like PDF) it knows how to deduce additional information. Well, than it will instantiate a BOT for PDF-files, fill in what's possible and link this new data-record to itself. Voila!
> This approach, if achievable, does away with data structures > and allows freeform queries to generate tabulated result sets (eg. > A "Show all invoice#, amounts" would know that amount is right > justified and prompt to include a total summary).
This would be something I want to include into a QUERY and REPORT dialect. Don't know how this looks like yet but I hope not like SQL ;-))
> Anyway, I hope something in the above is of value [to someone] ;)
Thanks a lot! Some of your ideas are what I want to achive with RFM, some are new and can/should be do able. I want to create a extendable, plug-in based system that can be extended very simple. Robert

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted