Re: save data in custom properties in a stack- or a text file?

2007-08-02 Thread Eric Chatonet

Hi Jacque,

Le 2 août 07 à 05:24, J. Landman Gay a écrit :

You can put info in custom properties and password-protect the  
stack, which makes the properties unreadable and encrypted.


Unfortunately (and this would be a nice to have), custom properties  
can be accessed as usual in a password protected stack.
But it's still possible to encrypt custom props and protect by  
password the code able to decipher them :-)


Best regards from Paris,
Eric Chatonet.

Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: [EMAIL PROTECTED]/



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: save data in custom properties in a stack- or a text file?

2007-08-02 Thread Josh Mellicker

Hi, and thanks for all your responses.




entering/reading data manually: text file way easier


What is manually in this context?  What other processes in the  
workflow require manual editing?


Basically I was saying typing stuff in a text file is easier than  
altering custom properties with a property editor and the message  
box; (mostly during development)



What if your data was this:

Revolution Coders
2.0

Richard,http://www.fourthworld.com/,http://www.fourthworld.com/rev/
Jacqueline,http://www.hyperactivesw.com,http://www.hyperactivesw.com/ 
Resources.html
Andre,http://andregarzia.com/,http://www.andregarzia.com/RevOnRockets/ 
index.html




Would you tend to store the above in a text file? Or custom props?



On a side note, this is how I'm encrypting a local text file with  
registration info:


function lbencrypt tData
encrypt tData using blowfish with password productInfo 
(regFilePassword)

put the base64encode of it into it
return it
end lbencrypt
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: save data in custom properties in a stack- or a text file?

2007-08-02 Thread J. Landman Gay

Eric Chatonet wrote:

Hi Jacque,

Le 2 août 07 à 05:24, J. Landman Gay a écrit :

You can put info in custom properties and password-protect the stack, 
which makes the properties unreadable and encrypted.


Unfortunately (and this would be a nice to have), custom properties can 
be accessed as usual in a password protected stack.
But it's still possible to encrypt custom props and protect by password 
the code able to decipher them :-)


True. But I was thinking about the file as it is stored on the server. 
If someone were to access the file and didn't have Rev to open it, they 
would have to look at it in a text editor or similar. In that case, none 
of the custom properties are readable if it is a password-protected 
stack. It's a crude type of protection, I admit, but it discourages 
casual attempts.


--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: save data in custom properties in a stack- or a text file?

2007-08-02 Thread Richard Gaskin

Josh Mellicker wrote:


entering/reading data manually: text file way easier


What is manually in this context?  What other processes in the  
workflow require manual editing?


Basically I was saying typing stuff in a text file is easier than  
altering custom properties with a property editor and the message  
box; (mostly during development)


If this manual editing only involves the developer it's a wash, since 
the developer can easily edit custom props.


And if for the user, whether a text file or a property it would be more 
convenient to provide a UI for editing such things, and I can't see why 
the UI for either would necessarily be more complicated than another.


One area where text files can be advantageous is when the file must be 
created by other software.  Other than that it seems a wash.



What if your data was this:

Revolution Coders
2.0

Richard,http://www.fourthworld.com/,http://www.fourthworld.com/rev/
Jacqueline,http://www.hyperactivesw.com,http://www.hyperactivesw.com/ 
Resources.html
Andre,http://andregarzia.com/,http://www.andregarzia.com/RevOnRockets/ 
index.html 



Would you tend to store the above in a text file? Or custom props?


For myself it would depend on a number of other factors:

- Will I ever need to store other lists related to this one?
- Will the system ever benefit from adding metadata to the data storage?
- How quickly will I need to access elements?
- Are such accesses more often sequential batches or individual items?


If I'm reading your posts correctly it sounds to my ear like you've 
already decided.  If it works, why change?


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: save data in custom properties in a stack- or a text file?

2007-08-02 Thread Josh Mellicker

Thanks for your illumination on this topic.

On Aug 2, 2007, at 9:29 AM, Richard Gaskin wrote:


If I'm reading your posts correctly it sounds to my ear like you've  
already decided.  If it works, why change?


I was just wondering if there was any case in which someone would  
store such a simple set of data in custom props rather than a text file.


I have learned the answer is yes!
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: save data in custom properties in a stack- or a text file?

2007-08-02 Thread Stephen Barncard
Again I say it's how you or your user use the data, and their skill 
in maintaining it without errors.
If you find yourself complaining about editing custom properties in 
the inspector, then take an hour and write a property editor that 
saves properties instead of saving as a text file. This allows you to 
control and contain the data easier.   If your users make errors 
editing text files (extra spaces, etc) then put the data entry under 
your control - verify each item before entry.




Hi, and thanks for all your responses.




entering/reading data manually: text file way easier


What is manually in this context?  What other processes in the 
workflow require manual editing?


Basically I was saying typing stuff in a text file is easier than 
altering custom properties with a property editor and the message 
box; (mostly during development)



What if your data was this:

Revolution Coders
2.0

Richard,http://www.fourthworld.com/,http://www.fourthworld.com/rev/
Jacqueline,http://www.hyperactivesw.com,http://www.hyperactivesw.com/Resources.html
Andre,http://andregarzia.com/,http://www.andregarzia.com/RevOnRockets/index.html



Would you tend to store the above in a text file? Or custom props?


--


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: save data in custom properties in a stack- or a text file?

2007-08-01 Thread Richard Gaskin

Josh Mellicker wrote:

I know stacks are a nice way to save a lot of data because it can be  
organized by custom property and custom property set.


But what about a simple list of data consisting of name, URL, and a  
couple other fields, that needs to be downloaded from a server- would  
you save the data in:


A. a stack in custom properties?
B. Or a text file?

The information in this case will never get more complicated, though  
is remotely possible a data field or two might be added in the  
future. But the data will never evolve to be complex, it will always  
merely be a list of files.



Here is my comparison:

writing to/reading from: code must be written for both, text file a  
little easier


Depends on what you're writing.  If you're just writing a single 
sequential list than dumping it to a file would be simple enough.  But 
if you need to access specific elements of that data, it's hard to beat 
the convenient flexibility and performance of array syntax to get custom 
prop elements.



entering/reading data manually: text file way easier


What is manually in this context?  What other processes in the 
workflow require manual editing?



encrypting: a tie

adding data fields: a tie, easy in either (you must think ahead)


Maybe, maybe not.  Again, it depends on the specifics of the 
implementation.  Adding a column to a list is easy enough, and using 
linked-listed to attach even large elements to property arrays can be 
easy enough, more efficient with large data, and possibly more flexible.



possible data corruption: a tie


Maybe, but consider this:

If you parse your own file yourself, you're responsible for defining the 
format and the accessors which will use that format, and must test your 
invention thoroughly.


But the custom property mechanism is already in the engine, already 
field-tested for more than a decade, and in all that time I've only even 
heard about three cases of true file corruption, and only seen one of 
those firsthand myself. Ten years is a long time.


Also, with stack files you get an automatic temporary backup whenever 
the save command is issued:  the last saved copy of the stack file is 
written to a temp file preceeded with a tilde (e.g., mystack.rev 
becomes ~mystack.rev), then the new stack file is written fresh from 
RAM contents, and only when the integrity of the completely fresh file 
has been checked is that temp file deleted.


So among other things this means that if your using has a power outage 
during a save, or any other unexpected interruption, the engine's 
handling of stack files automatically gives you a safety that's been 
proven in real-world work for many years.  You'd have to write that 
yourself if you wanted to provide similar protection.


Another plus for stack files:

With stack files you can add other lists, tables, metadata, even 
hierarchical data at any time without changing the accessors for your 
original data set. This inherent zero-cost extensibility is one of many 
reasons I've been migrating most of the apps I manage from custom 
formats to stack file formats.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: save data in custom properties in a stack- or a text file?

2007-08-01 Thread Stephen Barncard
there are so many ways and so many different solutions... all good. 
No method is inherently 'easier'. You have to focus on what's best 
for your user.  Will this be used by many or just one person? Does it 
need to travel with the app or does there need to be prefs for 
multiple users?


Text Files

If you're on a Mac, there are even more solutions.  On a recent 
'quick app' binge for a friend, I came up with a  solution for 
configuration storage that still had to be editable by the user.  And 
stays with the app (for now).


So although it was created as a double clickable application, 
option-clicking will reveal inside are more folders inside and those 
folders are areas (where the rev binary and external stacks live) 
where some data can be successfully written to by the app.  In order 
to not 'step on' the data I use the IDE and edit inside the 
package, with the added benefit that I don't have to recompile the 
standalone over and over and can test it immediately - and all the 
paths are already in place.


Available by menu, the app calls an Applescript call Reveal Folder 
and the client could take it from there and edit the little files 
that my app needs for part of the input (already stamped with their 
'creator' and 'type' tags by double clicking.I just saved having to 
re-invent the wheel for a little used but needed feature in my quick 
app.  The files then get edited in TextEdit. And the little files 
travel in the app with the client in her USB dongle.


specialfolderpath is good for multiple users at a workstation:

you can always call each platform's 
specialfolderpath(preferences) and put a folder in there with your 
app name and then put all sorts of files in there.


or if the user needs to get to the files sometimes  specialfolderpath(docs)

or if it's part of a urgent workflow  specialfolderpath(desktop)

Custom Props

Allow saving in a structured way, a hierarchy.

stack  card --property set-property properties 
lists inside of properties


It allows the clustering and associations one might get with files 
and folders, but in a better way.
But all the statements I made about WHERE to save still applies to 
stacks with custom properties as well as text files.


Text files, unless you use XML or some other method, are only one 
dimensional, and one ends up using different kinds of delimiters to 
keep the varied fields of data together in on file. Often faster to 
develop.


sqb


I know stacks are a nice way to save a lot of data because it can be 
organized by custom property and custom property set.


But what about a simple list of data consisting of name, URL, and a 
couple other fields, that needs to be downloaded from a server- 
would you save the data in:


A. a stack in custom properties?

B. Or a text file?


The information in this case will never get more complicated, though 
is remotely possible a data field or two might be added in the 
future. But the data will never evolve to be complex, it will always 
merely be a list of files.



Here is my comparison:

writing to/reading from: code must be written for both, text file a 
little easier


entering/reading data manually: text file way easier

encrypting: a tie

adding data fields: a tie, easy in either (you must think ahead)

possible data corruption: a tie



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



--


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: save data in custom properties in a stack- or a text file?

2007-08-01 Thread Mark Smith
One other consideration is how the data is to be used. Even though  
the data maybe simple, if you were going to load it into an array in  
your app, then saving it as a customPopertySet in a stack file might  
be easier.


from a text file to an array goes from
put URL file:someFile.txt  into tArray
split tArray by cr and =
to
put the customProperties[data] of stack whatever into tArray

Otherwise, and obviously if human-readability is an issue, I'd use a  
text file.



Best,

Mark

On 2 Aug 2007, at 00:09, Josh Mellicker wrote:

I know stacks are a nice way to save a lot of data because it can  
be organized by custom property and custom property set.


But what about a simple list of data consisting of name, URL, and a  
couple other fields, that needs to be downloaded from a server-  
would you save the data in:


A. a stack in custom properties?

B. Or a text file?


The information in this case will never get more complicated,  
though is remotely possible a data field or two might be added in  
the future. But the data will never evolve to be complex, it will  
always merely be a list of files.



Here is my comparison:

writing to/reading from: code must be written for both, text file a  
little easier


entering/reading data manually: text file way easier

encrypting: a tie

adding data fields: a tie, easy in either (you must think ahead)

possible data corruption: a tie



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: save data in custom properties in a stack- or a text file?

2007-08-01 Thread J. Landman Gay

Josh Mellicker wrote:
I know stacks are a nice way to save a lot of data because it can be 
organized by custom property and custom property set.


But what about a simple list of data consisting of name, URL, and a 
couple other fields, that needs to be downloaded from a server- would 
you save the data in:


A. a stack in custom properties?

B. Or a text file?


I like them both for different purposes. One of my apps needs a lot of 
little files on the server, and the client has to maintain them. They 
aren't critical files; it's stuff like a current table of contents, 
article summaries, that sort of thing. For this, text files are great. 
They are easy for him to edit and very fast for the app to read over the 
net. So I'd say if someone else has to maintain the files, go for text 
if you can. If you store that kind of info in a stack, you have to write 
tools for the person who maintains it.


For data my app maintains, either stacks or text files work fine. But 
stacks can provide an extra layer of protection if you need some 
security. You can put info in custom properties and password-protect the 
stack, which makes the properties unreadable and encrypted. Sometimes I 
also .gz the stack on the server (leaving off the extension) to make it 
a little harder to recognize it as a stack. It's not so secure that I'd 
store credit card info there, but it obscures things pretty well.


So both ways work, depending on what you need to do.

--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software   | http://www.hyperactivesw.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution