I suppose it can be anything.
For a project (serious game type) a game control object should have attached scripts that often do need to read from/write to files.
I was wondering whether there would be any interference with EZScript's internal behavior ?
Are there "default" file i/o affordances for Javascript in the
browser? I realize libraries such as Node.js and the like have
implemented server-side solutions, but I guess I've never really
needed to read/write to a file without some RESTful interchange
in-between.
Regarding JSON, I don't have as much experience as I would like, but
I've always felt JSON was an interchange format similar to XML which
wasn't so much a mechanism for reading/writing to files, but rather a
format to put them in just like CSV.
On Mon, Jul 9, 2012 at 1:53 AM, Michel DENIS <michel.m.de...@gmail.com> wrote:
> Hi José,
> I suppose it can be anything.
> For a project (serious game type) a game control object should have attached
> scripts that often do need to read from/write to files.
> I was wondering whether there would be any interference with EZScript's
> internal behavior ?
> -michel
> Jos Flores a écrit :
> is that JSON ?
> cheers,
> José
> On 8 July 2012 20:50, micheldenis <michel.m.de...@gmail.com> wrote:
> Hi Ryan
> For files reading & writing in OWL EZScript would you recommend using
> Javascript standard files I/O ?
> Are there "default" file i/o affordances for Javascript in the
> browser? I realize libraries such as Node.js and the like have
> implemented server-side solutions, but I guess I've never really
> needed to read/write to a file without some RESTful interchange
> in-between.
> Regarding JSON, I don't have as much experience as I would like, but
> I've always felt JSON was an interchange format similar to XML which
> wasn't so much a mechanism for reading/writing to files, but rather a
> format to put them in just like CSV.
> regards,
> -jW
> On Mon, Jul 9, 2012 at 1:53 AM, Michel DENIS <michel.m.de...@gmail.com> wrote:
>> Hi Jos�,
>> I suppose it can be anything.
>> For a project (serious game type) a game control object should have attached
>> scripts that often do need to read from/write to files.
>> I was wondering whether there would be any interference with EZScript's
>> internal behavior ?
>> -michel
>> Jos Flores a �crit :
>> is that JSON ?
>> cheers,
>> Jos�
>> On 8 July 2012 20:50, micheldenis <michel.m.de...@gmail.com> wrote:
>> Hi Ryan
>> For files reading & writing in OWL EZScript would you recommend using
>> Javascript standard files I/O ?
I think it depends on the use-case, the format of the file, and the
content of the file. Currently, I haven't written any way to read from
or write to a file.
On Mon, Jul 9, 2012 at 11:40 AM, Michel DENIS <michel.m.de...@gmail.com> wrote:
> Ryan,
> AFAIK there are not "default file" I/O functionality in server-side
> Javascript.
> What would you recommend then to perform file I/O from an EZScript ?
> Thank you,
> -michel
> jagwire a écrit :
> Michel,
> Are there "default" file i/o affordances for Javascript in the
> browser? I realize libraries such as Node.js and the like have
> implemented server-side solutions, but I guess I've never really
> needed to read/write to a file without some RESTful interchange
> in-between.
> Regarding JSON, I don't have as much experience as I would like, but
> I've always felt JSON was an interchange format similar to XML which
> wasn't so much a mechanism for reading/writing to files, but rather a
> format to put them in just like CSV.
> regards,
> -jW
> On Mon, Jul 9, 2012 at 1:53 AM, Michel DENIS <michel.m.de...@gmail.com>
> wrote:
> Hi José,
> I suppose it can be anything.
> For a project (serious game type) a game control object should have attached
> scripts that often do need to read from/write to files.
> I was wondering whether there would be any interference with EZScript's
> internal behavior ?
> -michel
> Jos Flores a écrit :
> is that JSON ?
> cheers,
> José
> On 8 July 2012 20:50, micheldenis <michel.m.de...@gmail.com> wrote:
> Hi Ryan
> For files reading & writing in OWL EZScript would you recommend using
> Javascript standard files I/O ?
Here when a user does some action, her/his "records" on disk need to be read and/or updated with some information.
The format of the file is flexible - I can format and parse at Javascript level.
Data are numbers, states info, .. you know like in games.
I understand that you currently have an "Include" method that reads files (like "startup.ez") from disk, so you have the functionality for reading.
Probably that for writing it is similar Java lines that would do it ?
Another option I was thinking about is to store that data within in-world objects, but not sure that properties can be used or extended for that purpose ?
The most obvious possibility I see is to use MakeShape then LabelShape with a text that contains the actual data I want to record on disk.
> I think it depends on the use-case, the format of the file, and the
> content of the file. Currently, I haven't written any way to read from
> or write to a file.
> -jW
> On Mon, Jul 9, 2012 at 11:40 AM, Michel DENIS <michel.m.de...@gmail.com> wrote:
>> Ryan,
>> AFAIK there are not "default file" I/O functionality in server-side
>> Javascript.
>> What would you recommend then to perform file I/O from an EZScript ?
>> Thank you,
>> -michel
>> jagwire a �crit :
>> Michel,
>> Are there "default" file i/o affordances for Javascript in the
>> browser? I realize libraries such as Node.js and the like have
>> implemented server-side solutions, but I guess I've never really
>> needed to read/write to a file without some RESTful interchange
>> in-between.
>> Regarding JSON, I don't have as much experience as I would like, but
>> I've always felt JSON was an interchange format similar to XML which
>> wasn't so much a mechanism for reading/writing to files, but rather a
>> format to put them in just like CSV.
>> regards,
>> -jW
>> On Mon, Jul 9, 2012 at 1:53 AM, Michel DENIS <michel.m.de...@gmail.com>
>> wrote:
>> Hi Jos�,
>> I suppose it can be anything.
>> For a project (serious game type) a game control object should have attached
>> scripts that often do need to read from/write to files.
>> I was wondering whether there would be any interference with EZScript's
>> internal behavior ?
>> -michel
>> Jos Flores a �crit :
>> is that JSON ?
>> cheers,
>> Jos�
>> On 8 July 2012 20:50, micheldenis <michel.m.de...@gmail.com> wrote:
>> Hi Ryan
>> For files reading & writing in OWL EZScript would you recommend using
>> Javascript standard files I/O ?
Hey guys, I simply mentioned JSON cause if you need to work with the
data from the file, if you read it in JSON you spare yourself all the
parsing (that you would have to do with XML or plain formats as comma
separated and so on).
cheers,
José
On 9 July 2012 20:33, Michel DENIS <michel.m.de...@gmail.com> wrote:
> Here when a user does some action, her/his "records" on disk need to be read
> and/or updated with some information.
> The format of the file is flexible - I can format and parse at Javascript
> level.
> Data are numbers, states info, .. you know like in games.
> I understand that you currently have an "Include" method that reads files
> (like "startup.ez") from disk, so you have the functionality for reading.
> Probably that for writing it is similar Java lines that would do it ?
> Another option I was thinking about is to store that data within in-world
> objects, but not sure that properties can be used or extended for that
> purpose ?
> The most obvious possibility I see is to use MakeShape then LabelShape with
> a text that contains the actual data I want to record on disk.
> What do you think Ryan ? Wouldn't it be nice to have file (or db) I/O from
> an EZScript ?
> -michel
> jagwire a écrit :
> Michel,
> I think it depends on the use-case, the format of the file, and the
> content of the file. Currently, I haven't written any way to read from
> or write to a file.
> -jW
> On Mon, Jul 9, 2012 at 11:40 AM, Michel DENIS <michel.m.de...@gmail.com>
> wrote:
> Ryan,
> AFAIK there are not "default file" I/O functionality in server-side
> Javascript.
> What would you recommend then to perform file I/O from an EZScript ?
> Thank you,
> -michel
> jagwire a écrit :
> Michel,
> Are there "default" file i/o affordances for Javascript in the
> browser? I realize libraries such as Node.js and the like have
> implemented server-side solutions, but I guess I've never really
> needed to read/write to a file without some RESTful interchange
> in-between.
> Regarding JSON, I don't have as much experience as I would like, but
> I've always felt JSON was an interchange format similar to XML which
> wasn't so much a mechanism for reading/writing to files, but rather a
> format to put them in just like CSV.
> regards,
> -jW
> On Mon, Jul 9, 2012 at 1:53 AM, Michel DENIS <michel.m.de...@gmail.com>
> wrote:
> Hi José,
> I suppose it can be anything.
> For a project (serious game type) a game control object should have attached
> scripts that often do need to read from/write to files.
> I was wondering whether there would be any interference with EZScript's
> internal behavior ?
> -michel
> Jos Flores a écrit :
> is that JSON ?
> cheers,
> José
> On 8 July 2012 20:50, micheldenis <michel.m.de...@gmail.com> wrote:
> Hi Ryan
> For files reading & writing in OWL EZScript would you recommend using
> Javascript standard files I/O ?
> -michel
> --
> Michel DENIS
> Président, Internet 3 Solutions SAS
> Tél: 06.72.87.17.50
> michel.de...@internet3solutions.com
> http://www.internet3solutions.com/
What you are speaking of reminds me of a common design pattern called
"Data Access Object". The idea is that you have a particularly simple
way of accessing your data be it from a database, a file, a RESTful
interface, etc... and this simple way does all the heavy lifting for
you. Because datasources are often personalized to the environment at
hand, the mechanisms for access are often specific to that
implementation. Try as I might, I don't think I would have the time to
write a DAO for every database, every restful interface, and every
filestore such that they're all easy to use even if a common format
(such as JSON as José suggested) were agreed upon. Script commands are
really not that hard to write, it's in the customer's best interest to
write their own DAO to guarantee quality.
On Mon, Jul 9, 2012 at 2:33 PM, Michel DENIS <michel.m.de...@gmail.com> wrote:
> Hello Ryan,
> Here when a user does some action, her/his "records" on disk need to be read
> and/or updated with some information.
> The format of the file is flexible - I can format and parse at Javascript
> level.
> Data are numbers, states info, .. you know like in games.
> I understand that you currently have an "Include" method that reads files
> (like "startup.ez") from disk, so you have the functionality for reading.
> Probably that for writing it is similar Java lines that would do it ?
> Another option I was thinking about is to store that data within in-world
> objects, but not sure that properties can be used or extended for that
> purpose ?
> The most obvious possibility I see is to use MakeShape then LabelShape with
> a text that contains the actual data I want to record on disk.
> What do you think Ryan ? Wouldn't it be nice to have file (or db) I/O from
> an EZScript ?
> -michel
> jagwire a écrit :
> Michel,
> I think it depends on the use-case, the format of the file, and the
> content of the file. Currently, I haven't written any way to read from
> or write to a file.
> -jW
> On Mon, Jul 9, 2012 at 11:40 AM, Michel DENIS <michel.m.de...@gmail.com>
> wrote:
> Ryan,
> AFAIK there are not "default file" I/O functionality in server-side
> Javascript.
> What would you recommend then to perform file I/O from an EZScript ?
> Thank you,
> -michel
> jagwire a écrit :
> Michel,
> Are there "default" file i/o affordances for Javascript in the
> browser? I realize libraries such as Node.js and the like have
> implemented server-side solutions, but I guess I've never really
> needed to read/write to a file without some RESTful interchange
> in-between.
> Regarding JSON, I don't have as much experience as I would like, but
> I've always felt JSON was an interchange format similar to XML which
> wasn't so much a mechanism for reading/writing to files, but rather a
> format to put them in just like CSV.
> regards,
> -jW
> On Mon, Jul 9, 2012 at 1:53 AM, Michel DENIS <michel.m.de...@gmail.com>
> wrote:
> Hi José,
> I suppose it can be anything.
> For a project (serious game type) a game control object should have attached
> scripts that often do need to read from/write to files.
> I was wondering whether there would be any interference with EZScript's
> internal behavior ?
> -michel
> Jos Flores a écrit :
> is that JSON ?
> cheers,
> José
> On 8 July 2012 20:50, micheldenis <michel.m.de...@gmail.com> wrote:
> Hi Ryan
> For files reading & writing in OWL EZScript would you recommend using
> Javascript standard files I/O ?
> -michel
> --
> Michel DENIS
> Président, Internet 3 Solutions SAS
> Tél: 06.72.87.17.50
> michel.de...@internet3solutions.com
> http://www.internet3solutions.com/
> It would certainly be nice to be able to do such.
> What you are speaking of reminds me of a common design pattern called
> "Data Access Object". The idea is that you have a particularly simple
> way of accessing your data be it from a database, a file, a RESTful
> interface, etc... and this simple way does all the heavy lifting for
> you. Because datasources are often personalized to the environment at
> hand, the mechanisms for access are often specific to that
> implementation. Try as I might, I don't think I would have the time to
> write a DAO for every database, every restful interface, and every
> filestore such that they're all easy to use even if a common format
> (such as JSON as Jos� suggested) were agreed upon. Script commands are
> really not that hard to write, it's in the customer's best interest to
> write their own DAO to guarantee quality.
> best regards,
> -jW
> On Mon, Jul 9, 2012 at 2:33 PM, Michel DENIS <michel.m.de...@gmail.com> wrote:
>> Hello Ryan,
>> Here when a user does some action, her/his "records" on disk need to be read
>> and/or updated with some information.
>> The format of the file is flexible - I can format and parse at Javascript
>> level.
>> Data are numbers, states info, .. you know like in games.
>> I understand that you currently have an "Include" method that reads files
>> (like "startup.ez") from disk, so you have the functionality for reading.
>> Probably that for writing it is similar Java lines that would do it ?
>> Another option I was thinking about is to store that data within in-world
>> objects, but not sure that properties can be used or extended for that
>> purpose ?
>> The most obvious possibility I see is to use MakeShape then LabelShape with
>> a text that contains the actual data I want to record on disk.
>> What do you think Ryan ? Wouldn't it be nice to have file (or db) I/O from
>> an EZScript ?
>> -michel
>> jagwire a �crit :
>> Michel,
>> I think it depends on the use-case, the format of the file, and the
>> content of the file. Currently, I haven't written any way to read from
>> or write to a file.
>> -jW
>> On Mon, Jul 9, 2012 at 11:40 AM, Michel DENIS <michel.m.de...@gmail.com>
>> wrote:
>> Ryan,
>> AFAIK there are not "default file" I/O functionality in server-side
>> Javascript.
>> What would you recommend then to perform file I/O from an EZScript ?
>> Thank you,
>> -michel
>> jagwire a �crit :
>> Michel,
>> Are there "default" file i/o affordances for Javascript in the
>> browser? I realize libraries such as Node.js and the like have
>> implemented server-side solutions, but I guess I've never really
>> needed to read/write to a file without some RESTful interchange
>> in-between.
>> Regarding JSON, I don't have as much experience as I would like, but
>> I've always felt JSON was an interchange format similar to XML which
>> wasn't so much a mechanism for reading/writing to files, but rather a
>> format to put them in just like CSV.
>> regards,
>> -jW
>> On Mon, Jul 9, 2012 at 1:53 AM, Michel DENIS <michel.m.de...@gmail.com>
>> wrote:
>> Hi Jos�,
>> I suppose it can be anything.
>> For a project (serious game type) a game control object should have attached
>> scripts that often do need to read from/write to files.
>> I was wondering whether there would be any interference with EZScript's
>> internal behavior ?
>> -michel
>> Jos Flores a �crit :
>> is that JSON ?
>> cheers,
>> Jos�
>> On 8 July 2012 20:50, micheldenis <michel.m.de...@gmail.com> wrote:
>> Hi Ryan
>> For files reading & writing in OWL EZScript would you recommend using
>> Javascript standard files I/O ?
>> -michel
>> --
>> Michel DENIS
>> Pr�sident, Internet 3 Solutions SAS
>> T�l: 06.72.87.17.50
>> michel.de...@internet3solutions.com
>> http://www.internet3solutions.com/
For awhile now I've wanted to be able to access a cell's sharedstate
capability from EZScript-land. This would allow one to write and
retrieve data from the information that gets saved into snapshots (and
subsnapshots) when they are taken. While the mechanics are trivial,
I'm trying to figure out a good syntax to use. I'm playing around with
the following in my head:
Context.put("name", "jagwire");
var name = Context.get("name");
var name = Global("name");
Global("name").set("jagwire");
and so on...
The trick is to make it as easy to use as possible.
On Thu, Jul 12, 2012 at 7:02 AM, Michel DENIS <michel.m.de...@gmail.com> wrote:
> Ryan,
> Any way to make persistence of data from EZScript methods ?
> -michel
> jagwire a écrit :
> Michel,
> It would certainly be nice to be able to do such.
> What you are speaking of reminds me of a common design pattern called
> "Data Access Object". The idea is that you have a particularly simple
> way of accessing your data be it from a database, a file, a RESTful
> interface, etc... and this simple way does all the heavy lifting for
> you. Because datasources are often personalized to the environment at
> hand, the mechanisms for access are often specific to that
> implementation. Try as I might, I don't think I would have the time to
> write a DAO for every database, every restful interface, and every
> filestore such that they're all easy to use even if a common format
> (such as JSON as José suggested) were agreed upon. Script commands are
> really not that hard to write, it's in the customer's best interest to
> write their own DAO to guarantee quality.
> best regards,
> -jW
> On Mon, Jul 9, 2012 at 2:33 PM, Michel DENIS <michel.m.de...@gmail.com>
> wrote:
> Hello Ryan,
> Here when a user does some action, her/his "records" on disk need to be read
> and/or updated with some information.
> The format of the file is flexible - I can format and parse at Javascript
> level.
> Data are numbers, states info, .. you know like in games.
> I understand that you currently have an "Include" method that reads files
> (like "startup.ez") from disk, so you have the functionality for reading.
> Probably that for writing it is similar Java lines that would do it ?
> Another option I was thinking about is to store that data within in-world
> objects, but not sure that properties can be used or extended for that
> purpose ?
> The most obvious possibility I see is to use MakeShape then LabelShape with
> a text that contains the actual data I want to record on disk.
> What do you think Ryan ? Wouldn't it be nice to have file (or db) I/O from
> an EZScript ?
> -michel
> jagwire a écrit :
> Michel,
> I think it depends on the use-case, the format of the file, and the
> content of the file. Currently, I haven't written any way to read from
> or write to a file.
> -jW
> On Mon, Jul 9, 2012 at 11:40 AM, Michel DENIS <michel.m.de...@gmail.com>
> wrote:
> Ryan,
> AFAIK there are not "default file" I/O functionality in server-side
> Javascript.
> What would you recommend then to perform file I/O from an EZScript ?
> Thank you,
> -michel
> jagwire a écrit :
> Michel,
> Are there "default" file i/o affordances for Javascript in the
> browser? I realize libraries such as Node.js and the like have
> implemented server-side solutions, but I guess I've never really
> needed to read/write to a file without some RESTful interchange
> in-between.
> Regarding JSON, I don't have as much experience as I would like, but
> I've always felt JSON was an interchange format similar to XML which
> wasn't so much a mechanism for reading/writing to files, but rather a
> format to put them in just like CSV.
> regards,
> -jW
> On Mon, Jul 9, 2012 at 1:53 AM, Michel DENIS <michel.m.de...@gmail.com>
> wrote:
> Hi José,
> I suppose it can be anything.
> For a project (serious game type) a game control object should have attached
> scripts that often do need to read from/write to files.
> I was wondering whether there would be any interference with EZScript's
> internal behavior ?
> -michel
> Jos Flores a écrit :
> is that JSON ?
> cheers,
> José
> On 8 July 2012 20:50, micheldenis <michel.m.de...@gmail.com> wrote:
> Hi Ryan
> For files reading & writing in OWL EZScript would you recommend using
> Javascript standard files I/O ?
> -michel
> --
> Michel DENIS
> Président, Internet 3 Solutions SAS
> Tél: 06.72.87.17.50
> michel.de...@internet3solutions.com
> http://www.internet3solutions.com/
> --
> Michel DENIS
> Président, Internet 3 Solutions SAS
> Tél: 06.72.87.17.50
> michel.de...@internet3solutions.com
> http://www.internet3solutions.com/
This looks fine, especially if implementation is not difficult.
Such fonctionality might look simple, but has an enormous potential of use in Wonderland scripting, I think !
We could create objects, with properties like "name" and values like "jagwire" (in your example).
Thinking that the more we get result value, the best it will be, so may I suggest that "put"/"set" ("set" is my preference) also have a result "var" just like you seem to plan for "get".
If on top of the above 2 operations one would like a few more, I'd vote for: "create" and "delete", except if put automatically creates the property in case it does not exist yet.
Would it be possible to implement a first-phase version of that functionality ?
> For awhile now I've wanted to be able to access a cell's sharedstate
> capability from EZScript-land. This would allow one to write and
> retrieve data from the information that gets saved into snapshots (and
> subsnapshots) when they are taken. While the mechanics are trivial,
> I'm trying to figure out a good syntax to use. I'm playing around with
> the following in my head:
> Context.put("name", "jagwire");
> var name = Context.get("name");
> var name = Global("name");
> Global("name").set("jagwire");
> and so on...
> The trick is to make it as easy to use as possible.
> -jW
> On Thu, Jul 12, 2012 at 7:02 AM, Michel DENIS <michel.m.de...@gmail.com> wrote:
>> Ryan,
>> Any way to make persistence of data from EZScript methods ?
>> -michel
>> jagwire a �crit :
>> Michel,
>> It would certainly be nice to be able to do such.
>> What you are speaking of reminds me of a common design pattern called
>> "Data Access Object". The idea is that you have a particularly simple
>> way of accessing your data be it from a database, a file, a RESTful
>> interface, etc... and this simple way does all the heavy lifting for
>> you. Because datasources are often personalized to the environment at
>> hand, the mechanisms for access are often specific to that
>> implementation. Try as I might, I don't think I would have the time to
>> write a DAO for every database, every restful interface, and every
>> filestore such that they're all easy to use even if a common format
>> (such as JSON as Jos� suggested) were agreed upon. Script commands are
>> really not that hard to write, it's in the customer's best interest to
>> write their own DAO to guarantee quality.
>> best regards,
>> -jW
>> On Mon, Jul 9, 2012 at 2:33 PM, Michel DENIS <michel.m.de...@gmail.com>
>> wrote:
>> Hello Ryan,
>> Here when a user does some action, her/his "records" on disk need to be read
>> and/or updated with some information.
>> The format of the file is flexible - I can format and parse at Javascript
>> level.
>> Data are numbers, states info, .. you know like in games.
>> I understand that you currently have an "Include" method that reads files
>> (like "startup.ez") from disk, so you have the functionality for reading.
>> Probably that for writing it is similar Java lines that would do it ?
>> Another option I was thinking about is to store that data within in-world
>> objects, but not sure that properties can be used or extended for that
>> purpose ?
>> The most obvious possibility I see is to use MakeShape then LabelShape with
>> a text that contains the actual data I want to record on disk.
>> What do you think Ryan ? Wouldn't it be nice to have file (or db) I/O from
>> an EZScript ?
>> -michel
>> jagwire a �crit :
>> Michel,
>> I think it depends on the use-case, the format of the file, and the
>> content of the file. Currently, I haven't written any way to read from
>> or write to a file.
>> -jW
>> On Mon, Jul 9, 2012 at 11:40 AM, Michel DENIS <michel.m.de...@gmail.com>
>> wrote:
>> Ryan,
>> AFAIK there are not "default file" I/O functionality in server-side
>> Javascript.
>> What would you recommend then to perform file I/O from an EZScript ?
>> Thank you,
>> -michel
>> jagwire a �crit :
>> Michel,
>> Are there "default" file i/o affordances for Javascript in the
>> browser? I realize libraries such as Node.js and the like have
>> implemented server-side solutions, but I guess I've never really
>> needed to read/write to a file without some RESTful interchange
>> in-between.
>> Regarding JSON, I don't have as much experience as I would like, but
>> I've always felt JSON was an interchange format similar to XML which
>> wasn't so much a mechanism for reading/writing to files, but rather a
>> format to put them in just like CSV.
>> regards,
>> -jW
>> On Mon, Jul 9, 2012 at 1:53 AM, Michel DENIS <michel.m.de...@gmail.com>
>> wrote:
>> Hi Jos�,
>> I suppose it can be anything.
>> For a project (serious game type) a game control object should have attached
>> scripts that often do need to read from/write to files.
>> I was wondering whether there would be any interference with EZScript's
>> internal behavior ?
>> -michel
>> Jos Flores a �crit :
>> is that JSON ?
>> cheers,
>> Jos�
>> On 8 July 2012 20:50, micheldenis <michel.m.de...@gmail.com> wrote:
>> Hi Ryan
>> For files reading & writing in OWL EZScript would you recommend using
>> Javascript standard files I/O ?
