rebol-framework: information

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

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: >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 ;-)) >

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

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

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

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

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

> function? (e.g. to use parse rules to define some custom datatypes)

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

> 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

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

> 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

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

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

>>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 >RFM as the single application that supports integration/assocication >between every piece of data.

> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]] > Subject: [REBOL] Re: rebol-framework: information > yes, that is what I had in mind ...

> ... which I personally find pretty messy aproach to UI .... myriads of > separate windows - confusion.

> 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 :-)

> and what if others have complete different idea of how to represent

> and their relations in UI?

> If RFM can't provide such functionality separation), it kills its

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

> yes, but RFM already offers also GUI. So what will happen with IOS > desktop and its reblets?

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)

<snip> > >I don't think this makes sense. To create a good GUI is like a "black > > > noone does :-)

> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]] > Subject: [REBOL] Re: rebol-framework: information > Hey, I kinda like it and Cyphre says he loves it! ;-)

> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]] > Subject: [REBOL] Re: rebol-framework: information > I agree, web based forms are a waste of space and time...

> Where do I find RFM?

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

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

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

Ashley Truter wrote:

> Hi Robert, > Read your doco and the conceptual basis looks pretty sound to me. I've > to run receives and generates a lot of data in multiple formats (many > of them not electronic).

> 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 > 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 > 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 > 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).

> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]] > Read your doco and the conceptual basis looks pretty sound to > me.

> 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 > manilla folders > notepad / sticky note

> which then depend upon disparate means of archival and retrieval: > electronic file system > 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 > (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: > (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.

> 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. > A "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] ;)