IOS data

Hi, I'm thinking about the same thing (not especially for IOS) but for a general Rebol based collection of tools, which should integrate well.

Well, how data is stored isn't that ciritical. You can use a database, text file etc. IMO what's most needed is a description about the (business) objects those tools should handle. If we all could agree on a standard way what information a contact-entry contains, than it's up to the community to create applications, which use those objects. So I propose to start with a collection of descriptions for those objects, so that we all can base our work on these discriptions. It should even be possible to handle different versions of those objects, as Rebol supports checks about the presense of words in objects. What do you think? Robert

Hi,

How? value? obj/word ??? If word doesn't exist, it fails ... or - in obj 'word? -pekr-

hmm... Presumably it will work according to how you want/need it to work.. people-people is about workflow so the workflow determines the topology [or it should]. The topology also affects the workflow, which is partly why imo internet/web groupware is so ****ed in so many ways. I imagine a hybrid of local servers, smart clients and communal centralized repositories. Why should all your own be housed centrally as long as people find and access it appropriately? Ditto for larger group of people, having a common central repository may be an essential starting datum level against which local reblets and relationships are based [www.rebol.com is one now] Where the base data is large and common, say a multiple layers of a big mapping applications, centralizing it makes sense, but so does having a ROM or Hard drive cache of same. As each individual or workgourp begin to edit their own versions and compile metadata, one must ask deeply when if ever that needs to be centralized and synchronized or whether it should remain as distributed metadata In nay event I cannot see why every device should not fundamentally embed client and server modules. These are quiet simply the ubiquitous yin and yang of communications [look at your telephone handset for a global example] . With these building blocks all kinds of permutations are possible. Hopefully the poor marketing [un]-inspired vocabulary of "peer-to-peer" we have now, will give way to much better more open map-like language and thinking. My Hope for Rebol/++/IOS etc is that the rather false distinctions we have at present will dissolve and be revealed for the illusion they are. That we will be able to play NetLego, building new parts, coloring them . That we will together be creating Reblets, elements, mappings and applications which are the equivalent of some super net-synthesizer. That we can visualize and patch them as a design aid but also a maintenance adn operational interface without changing much. For more on this download the PD [Pure Data] toolkit I posted about and start playing around. Then imagine these are Rebol/IOS patches you are manipulating..! http://www-crca.ucsd.edu/~msp/software.html http://www.crca.ucsd.edu/~msp/Pd_documentation/index.htm We live in interesting times - Jason

objects, so

possible

about

'word? Here is an example from a couple of apps that share data. Each of the apps has slightly extended a msg obj. (Note: This is from express beta, and not necessarily representative of the new IOS framework) 1. Presumably you know which features or fields in the data your app supports. So you create a template object for the data, complete with default values (in this case I set all to none). msg-obj: context [fx: who: when: color: content: file: group: none] 2. the data is a simple block (which could be loaded from a file) [who: "Allen" when: 2-Oct-2001/22:54:47+10:00 color: 200.100.50 file: %msg0001.r group: "support" offset: 0x0 refresh: 1:00:00 content: "Test Messgage"] 3. Make our object if error? try [msg: make msg-obj load data][msg: make msg-obj []] make object! [ fx: none who: "Allen" when: 2-Oct-2001/22:54:47+10:00 color: 200.100.50 content: "Test Message" file: %msg0001.r group: "support" offset: 0x0 refresh: 1:00 ] (Note how compact and extensible the REBOL block format is compared to XML for transfering simple data.) 4. Now I can use the parameters of the object that my script knows about. I can ignore the paremeters that I don't know about. And I can test for ones I expect because of my defaults in the template. if msg/fx [do really amazing fx stuff] if msg/who [print ["Msg for " msg/who] 5. You can also find out if other words are present in the object,

== true

== false 5. If I wanted to save this msg object I would use save msg-file third msg Cheers, Allen K

'word?

what about this: error? try [get in obj 'word] or another method... find first obj 'word regards, Cyphre

extend-object: func ['obj-word [word!] 'word [word!] value [any-type!] /local the-obj][ all [not object? the-obj: get obj-word make error! "No object provided."] if in the-obj word [ set in the-obj word value return the-obj ] set obj-word make the-obj reduce [to-set-word word value] ] Robert

tools

applications,

so

possible

about

Building a collection of these objects would be an excellent idea. This would give a common base to store this information along the lines of IBMs SanFransico business objects (although hopefully less complicated). As Jason points out, there the location of the data should ideally be irrelevant - of course. I guess the only system which comes close to this at the moment is the old Lotus Notes system whereby cross-platform clients are designed to access either locally cloned copies or network based 'databases' to store information. In the Notes case this is implemented as an inflexible closed system, but using a similar concept with a distributed data store, services for data replication (link?), and peer to peer connectivity some amazing products could be built. Defining this core set of objects may be quite a task though. I have to admit, I wouldn't know where to start in designing all this :) cheers, John