Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
John Carlson wrote: The way I read rest over http post (wikipedia) is that you either create a new entry in a collection uri, or you create a new entry in the element uri, which becomes a collection. So one still needs a way to add several entries to a collection, or one needs something like couchdb. I read in rfc2616 quoted on stackoverflow that clients should not pipeline non-idempotent methods or non-idempotent sequences of methods. So basically that tosses pipelining of posts. Face it, REST over HTTP is slow when backed by a large relational database (I'm not exactly sure how large, but considering where it's at it could get quite large). If you want the particulars, please contact Duncan Scott at JGI he is the one who did the benchmarking. He also thought it would be good to use CouchDB as a possible replacement. Instead of using couchdb, we started down the path of writing our own collection submittal services. I can't say anything about REST in general being slow. I would like to see better support for adding multiple objects to a collection in HTTP REST, perhap by using MIME. So you're saying that somebody, did some kind of benchmark, between 2 different, and undefined interfaces to a large relational database, and based on that you're making a global statement that REST over HTTP is slow when backed by a large relational database - and that if we disagree with this global assertion, we should take it up with that other guy. Really? -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Feb 15, 2013, at 12:10 AM, John Carlson yottz...@gmail.com wrote: I can't say anything about REST in general being slow. I would like to see better support for adding multiple objects to a collection in HTTP REST, perhap by using MIME. REST is not a highly efficient protocol by any means but most of the slowness people attribute to REST has more to do with what people transport inside a REST operation than REST itself. REST is often below the performance noise floor if it is well-used despite its inefficiencies. REST is commonly used to transport XML or JSON or similar. Parsing JSON or XML encoding structures is quite slow because they are intrinsically inefficient as wire encoding formats. Compared to common efficient encodings, the difference in cost exceeds an order of magnitude in practice. For example, I currently have a system that parses, processes, and indexes complex geodetic polygons at sustained rates of many gigabytes per second (for real-time petabyte-scale sensing models of the Earth). The largest total consumer of CPU time by far is not computational geometry, network processing, or anything like that but parsing JSON source formats -- and we've invested a lot of time in highly optimizing JSON parsing. The internal binary format used by the same system disappears below the noise floor. As a practical matter, most people that use REST use JSON or XML and most people that don't use JSON and XML also don't use REST for related reasons. But it is not fair to blame REST for what is primarily an issue with JSON and XML even though they are often seen together. REST is not efficient but it usually pretty low on the long list of things that are slowing down an application. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Fri, Feb 15, 2013 at 12:10 AM, John Carlson yottz...@gmail.com wrote: The way I read rest over http post (wikipedia) is that you either create a new entry in a collection uri, or you create a new entry in the element uri, which becomes a collection. There are other options. For example, if you have a URI that represents a particular subset of records in a table (i.e. perhaps the URI itself contains a WHERE clause) then you could GET or PUT (or DELETE) just that subset of records in a sensible and RESTful manner. (Alternatively, you can PUT a resource that defines a view, then PUT some values into the view's results. But this requires code distribution, which is unpopular for a lot of security reasons.) For REST in general, the resource identifier schema can be a lot more flexible or structured than HTTP's URIs (and aren't necessarily limited to a few kilobytes). But even HTTP's URIs can be applied creatively. I read in rfc2616 quoted on stackoverflow that clients should not pipeline non-idempotent methods or non-idempotent sequences of methods. So basically that tosses pipelining of posts. Face it, REST over HTTP is slow PUTs are idempotent and can safely be pipelined. It isn't clear to me why you're using POST as the measure for REST performance. (POST is not very RESTful. The content of POST does not represent the state of any existing resource. It takes discipline to consistently use POST in a RESTful manner. POST is effectively HTTP's version of RPC, with all the attendant problems. GET and PUT are both much more closely aligned with REST.) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
If you have to start a new relational database transaction for each http post when submitting hundreds of posts, that's going to create a lot of overhead, if you choose to use session ids and leave the tranaction open, then you risk not committing something. If you use database pools, you are protected both ways I believe. Still, that's a lot of open connections. On Feb 15, 2013 2:58 AM, J. Andrew Rogers and...@jarbox.org wrote: On Feb 15, 2013, at 12:10 AM, John Carlson yottz...@gmail.com wrote: I can't say anything about REST in general being slow. I would like to see better support for adding multiple objects to a collection in HTTP REST, perhap by using MIME. REST is not a highly efficient protocol by any means but most of the slowness people attribute to REST has more to do with what people transport inside a REST operation than REST itself. REST is often below the performance noise floor if it is well-used despite its inefficiencies. REST is commonly used to transport XML or JSON or similar. Parsing JSON or XML encoding structures is quite slow because they are intrinsically inefficient as wire encoding formats. Compared to common efficient encodings, the difference in cost exceeds an order of magnitude in practice. For example, I currently have a system that parses, processes, and indexes complex geodetic polygons at sustained rates of many gigabytes per second (for real-time petabyte-scale sensing models of the Earth). The largest total consumer of CPU time by far is not computational geometry, network processing, or anything like that but parsing JSON source formats -- and we've invested a lot of time in highly optimizing JSON parsing. The internal binary format used by the same system disappears below the noise floor. As a practical matter, most people that use REST use JSON or XML and most people that don't use JSON and XML also don't use REST for related reasons. But it is not fair to blame REST for what is primarily an issue with JSON and XML even though they are often seen together. REST is not efficient but it usually pretty low on the long list of things that are slowing down an application. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Fri, Feb 15, 2013 at 12:56 AM, J. Andrew Rogers and...@jarbox.orgwrote: REST is not a highly efficient protocol by any means Indeed. REST isn't even a protocol. The largest total consumer of CPU time [.. is ..] parsing JSON source formats While this is a good point, it isn't clear to me that it applies more to RESTful communication systems than to others. Even SOAP or RPC often uses structured text. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
Andrew, J. Andrew Rogers wrote: On Feb 15, 2013, at 12:10 AM, John Carlson yottz...@gmail.com wrote: I can't say anything about REST in general being slow. I would like to see better support for adding multiple objects to a collection in HTTP REST, perhap by using MIME. REST is not a highly efficient protocol by any means but most of the slowness people attribute to REST has more to do with what people transport inside a REST operation than REST itself. REST is often below the performance noise floor if it is well-used despite its inefficiencies. I agree with your conclusions, but I have to say that statements like this drive me absolutely crazy - for several reasons - the main one being that REST is not a protocol - it's an architectural style / a design pattern for designing APIs - primarily APIs that are carried over HTTP (which IS a protocol). And the contrast is usually made to W3C style web services - which is a very different way of defining and carrying transactions over HTTP (mostly involving lots of XML and lots of extraneous headers that are usually left empty). REST is commonly used to transport XML or JSON or similar. Parsing JSON or XML encoding structures is quite slow because they are intrinsically inefficient as wire encoding formats. Now, if you want to say encoding transactions as XML or JSON, and executing them over HTTP, is slow - that's probably an accurate statement over HTTP, is slow - that might or might not be an accurate statement - depending on what you're comparing to. Wrap the same transaction in SOAP headers (per W3C web service specifications), and run it over HTTP, and you'll slow things down a lot. Push the transaction over a raw TCP socket connection, and it will be marginally faster. Compared to common efficient encodings, the difference in cost exceeds an order of magnitude in practice. For example, I currently have a system that parses, processes, and indexes complex geodetic polygons at sustained rates of many gigabytes per second (for real-time petabyte-scale sensing models of the Earth). The largest total consumer of CPU time by far is not computational geometry, network processing, or anything like that but parsing JSON source formats -- and we've invested a lot of time in highly optimizing JSON parsing. The internal binary format used by the same system disappears below the noise floor. And now we're back to matters that really make a difference, but that are orthogonal to REST. You can push things other than XML and JSON over HTTP, and you can do it in a RESTful manner or not. And you can push things across the net using other kinds of protocols. For the application that you describe - streaming huge datasets - RESTful interfaces, and HTTP, are probably not particularly effective. As a practical matter, most people that use REST use JSON or XML and most people that don't use JSON and XML also don't use REST for related reasons. But it is not fair to blame REST for what is primarily an issue with JSON and XML even though they are often seen together. REST is not efficient but it usually pretty low on the long list of things that are slowing down an application. I'm not sure I completely agree with you here. There are an awful lot of RESTful interfaces to things like imagery and map databases. What makes them restful is how data is addressed (by URL), and the use of HTTP operations to GET/PUT/DELETE data, but the actual data formats are content specific (audio formats, video formats, shape files, etc.) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Fri, Feb 15, 2013 at 1:22 AM, John Carlson yottz...@gmail.com wrote: If you have to start a new relational database transaction for each http post when submitting hundreds of posts, that's going to create a lot of overhead, if you choose to use session ids and leave the tranaction open, then you risk not committing something. If you use database pools, you are protected both ways I believe. A technique I've seen used (albeit, only once or twice) is to batch updates from multiple connections, and run batches at 20+Hz while there is demand for them. This only requires one connection from the server to its database, and allows you to respond and close each HTTP connection in a predictable amount of time, and allows you to ensure the updates are committed before replying. The limitation of this technique is that you can't have ad-hoc updates, since those would be too difficult to batch consistently and sensibly. It's a bit specialized, but is able to handle a lot of updates. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
The most important paragraph is at the bottom. It depends on the implementation of PUT. If it's implemented as a delete followed by an insert, then it's likely you've lost data like created date, unless you write some clever triggers. If it's implemented as an update then there's also a chance that you've lost your created date, because a different date could come in from the cliented. Sometimes people really depend on created date and this means hiding it from the client, which means writing one off rest services for all your database tables that have created date. You can also write PUT as a falied insert followed by an update. This often involves writing a special database procedure. You can also do a select before doing all of this, but whoever is coming after you maintaining the code is going to say WTF. Yes I know that some of this can be handled by ORM, then you lose your ability to cache if the data is accesed outside the ORM, perhaps in some reporting framework. I believe the best thing to do is use POST to create objects and quit trying to fool people with your smartness. You're only asking for trouble if you do otherwise. The important thing is to make sure your operations are idempotent when they should be...that means with failures as well. I think if you're using POSTs not according to the REST HTTP spec you're asking for all kinds of trouble. As far as I can tell, they should only be used to add items to collections. On Feb 15, 2013 3:13 AM, David Barbour dmbarb...@gmail.com wrote: On Fri, Feb 15, 2013 at 12:10 AM, John Carlson yottz...@gmail.com wrote: The way I read rest over http post (wikipedia) is that you either create a new entry in a collection uri, or you create a new entry in the element uri, which becomes a collection. There are other options. For example, if you have a URI that represents a particular subset of records in a table (i.e. perhaps the URI itself contains a WHERE clause) then you could GET or PUT (or DELETE) just that subset of records in a sensible and RESTful manner. (Alternatively, you can PUT a resource that defines a view, then PUT some values into the view's results. But this requires code distribution, which is unpopular for a lot of security reasons.) For REST in general, the resource identifier schema can be a lot more flexible or structured than HTTP's URIs (and aren't necessarily limited to a few kilobytes). But even HTTP's URIs can be applied creatively. I read in rfc2616 quoted on stackoverflow that clients should not pipeline non-idempotent methods or non-idempotent sequences of methods. So basically that tosses pipelining of posts. Face it, REST over HTTP is slow PUTs are idempotent and can safely be pipelined. It isn't clear to me why you're using POST as the measure for REST performance. (POST is not very RESTful. The content of POST does not represent the state of any existing resource. It takes discipline to consistently use POST in a RESTful manner. POST is effectively HTTP's version of RPC, with all the attendant problems. GET and PUT are both much more closely aligned with REST.) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
The last they should be POSTs. Forgive my typos. For some unknown reason I am using my phone On Feb 15, 2013 3:52 AM, John Carlson yottz...@gmail.com wrote: The most important paragraph is at the bottom. It depends on the implementation of PUT. If it's implemented as a delete followed by an insert, then it's likely you've lost data like created date, unless you write some clever triggers. If it's implemented as an update then there's also a chance that you've lost your created date, because a different date could come in from the cliented. Sometimes people really depend on created date and this means hiding it from the client, which means writing one off rest services for all your database tables that have created date. You can also write PUT as a falied insert followed by an update. This often involves writing a special database procedure. You can also do a select before doing all of this, but whoever is coming after you maintaining the code is going to say WTF. Yes I know that some of this can be handled by ORM, then you lose your ability to cache if the data is accesed outside the ORM, perhaps in some reporting framework. I believe the best thing to do is use POST to create objects and quit trying to fool people with your smartness. You're only asking for trouble if you do otherwise. The important thing is to make sure your operations are idempotent when they should be...that means with failures as well. I think if you're using POSTs not according to the REST HTTP spec you're asking for all kinds of trouble. As far as I can tell, they should only be used to add items to collections. On Feb 15, 2013 3:13 AM, David Barbour dmbarb...@gmail.com wrote: On Fri, Feb 15, 2013 at 12:10 AM, John Carlson yottz...@gmail.comwrote: The way I read rest over http post (wikipedia) is that you either create a new entry in a collection uri, or you create a new entry in the element uri, which becomes a collection. There are other options. For example, if you have a URI that represents a particular subset of records in a table (i.e. perhaps the URI itself contains a WHERE clause) then you could GET or PUT (or DELETE) just that subset of records in a sensible and RESTful manner. (Alternatively, you can PUT a resource that defines a view, then PUT some values into the view's results. But this requires code distribution, which is unpopular for a lot of security reasons.) For REST in general, the resource identifier schema can be a lot more flexible or structured than HTTP's URIs (and aren't necessarily limited to a few kilobytes). But even HTTP's URIs can be applied creatively. I read in rfc2616 quoted on stackoverflow that clients should not pipeline non-idempotent methods or non-idempotent sequences of methods. So basically that tosses pipelining of posts. Face it, REST over HTTP is slow PUTs are idempotent and can safely be pipelined. It isn't clear to me why you're using POST as the measure for REST performance. (POST is not very RESTful. The content of POST does not represent the state of any existing resource. It takes discipline to consistently use POST in a RESTful manner. POST is effectively HTTP's version of RPC, with all the attendant problems. GET and PUT are both much more closely aligned with REST.) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
J. Andrew Rogers and...@jarbox.org writes:
On Feb 15, 2013, at 12:10 AM, John Carlson yottz...@gmail.com wrote:
REST is commonly used to transport XML or JSON or similar. Parsing
JSON or XML encoding structures is quite slow because they are
intrinsically inefficient as wire encoding formats. Compared to common
efficient encodings, the difference in cost exceeds an order of
magnitude in practice.
What you say is true, but if we're getting into custom binary formats
then there's a danger of comparing apples to oranges. The usual debate I
see is between REST and SOAP. SOAP is inherently an XML delivery
platform, otherwise there's an 'inner-platform' issue, so in this
respect the performance comparison is much closer to a RESTful XML
services than a custom binary format would be.
SOAP can be seen as an object synchronisation mechanism, where the
clients get proxy objects and pretend they replicate (some of) the state
of the server's objects. To keep the overhead down, SOAP will usually
wrap 'large' objects, ie. where a single method call can trigger a lot
of computation, and order-of-execution can matter, eg.
'update(); doA(); doB(); doC();' rather than
'updateAndDoA(); updateAndDoB(); updateAndDoC();', where the former
relies heavily on the up-to-date state persisting between method calls.
As has been mentioned on this list many times, distributed object
synchronisation is a very difficult issue, and re-implementing it for
every application that uses SOAP is a large drain on resources. This is
why I prefer REST.
REST doesn't suffer the synchronisation problem since it doesn't have
any shared state at all. Clients may decide to base future requests on
past responses, but such state is private to the client and is assumed
to be out-of-date as soon as it arrives; to make this out-of-date data
useful, a lot of the server's state will be immutable (eg. consistent
IDs, revision-based updating, etc.).
Since REST clients can't rely on chaining requests to set up their
context, each call needs to contain all of the details required to
fulfil the request. This is where the performance confusion can creep
in: shared state is replaced by in-band data. Of course, the key is that
the REST interface should be tailored to what the clients need.
Taking a SOAP API, which is suited to 'large' objects, and naively
turning it into a REST API will end up with massive requests. A SOAP API
may update a user's email address by requesting a User object for user
123, then calling setEmail('u...@example.com'). This is low overhead
since the only transmissions were a proxy object and an email address
(and presumably a response). Transliterating this into REST would GET
example.com/user/123, dragging in a whole user record, then PUT the
whole thing (with a new address) to example.com/user/123. This is highly
inefficient and also breaks the out-of-date results assumption (any
intervening changes would be clobbered). The correct way to do this
would PUT 'u...@example.com' to example.com/user/123/email.
When implementing REST correctly, the only overhead should be a small,
constant amount due to the verbosity of authentication. In SOAP this is
only needed during the initial setup, since a pseudorandom session ID
can be used in subsequent requests. In practice, many REST
implementations use a non-RESTful session ID like this too.
Chris
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Fri, Feb 15, 2013 at 1:52 AM, John Carlson yottz...@gmail.com wrote: I believe the best thing to do is use POST to create objects and quit trying to fool people with your smartness. You're only asking for trouble if you do otherwise. Ah, the people are too dumb to understand anything but tradition argument. I think the concept of 'creation' is not a very good one, not least because it isn't idempotent. I have patterns and idioms to make do without it. means writing one off rest services for all your database tables that have created date. If you do such a thing for three or more tables, you should start developing a reusable abstraction! If I needed to preserve created date or other metadata, I'd consider modeling it as part of the key. As far as I can tell, [POSTS] should only be used to add items to collections. Sure, but that can mean anything at all. Adding procedure activation records to a stack, or print requests to a queue, are examples of adding items to collections. POST is equivalent to RPC, even if you phrase it as adding items to collections. The important thing is to make sure your operations are idempotent when they should be...that means with failures as well. There are many other important things, such as clearly documenting for your clients and intermediate services which of your operations are safe, idempotent, cacheable, etc.. The reason REST does well in-the-large (extensibility, integration, disruption, scalability, etc.) is because of the clear, end-to-end understandings about the properties of operations. If you use POST, even in an idempotent manner, you lose a lot of value in-the-large. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] collections and rest
I am confused. 100 objects can as easily be created in one transaction as in a hundred transactions, can they not? Are you (John) trying to say that REST has some impact on a client's ability to enclose 100 objects in one transaction? This may be true: I have never tried big transactions over HTTP / REST. If it is, what impact, and how does it relate to FONC? Have fun! David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] collections and rest
I mistakenly wrote: I am confused. 100 objects can as easily be created in one transaction as in a hundred transactions, can they not? ... Please ignore that message, which both represented my misunderstanding of the HTTP PUT method, and did not take into account the full context of the conversation. (I have since found the relevant thread.) Sorry for the noise. Have fun! David ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
The most valuable part of the POST is the database generated ID. I realize there are other ways to do this--batching the creation of IDs for example. One needs IDs before doing PUTs and GETs. Yes I understand the value of obfuscating IDs for security reasons. I don't really agree with showing any IDs to the user. I will take your words of advice and try to avoid non-idempotent operations. Seems like a good thing. The rpc operations you list below seem like good reasons for using post. Don't assume people read your documentation. And don't blame them if they don't. Some people have reading disabilities. You should feel lucky if you have your full capabilities. If you expose your created date as a key, then people might be apt to put collections with their own created dates. You need to test for realism. On Feb 15, 2013 4:29 AM, David Barbour dmbarb...@gmail.com wrote: On Fri, Feb 15, 2013 at 1:52 AM, John Carlson yottz...@gmail.com wrote: I believe the best thing to do is use POST to create objects and quit trying to fool people with your smartness. You're only asking for trouble if you do otherwise. Ah, the people are too dumb to understand anything but tradition argument. I think the concept of 'creation' is not a very good one, not least because it isn't idempotent. I have patterns and idioms to make do without it. means writing one off rest services for all your database tables that have created date. If you do such a thing for three or more tables, you should start developing a reusable abstraction! If I needed to preserve created date or other metadata, I'd consider modeling it as part of the key. As far as I can tell, [POSTS] should only be used to add items to collections. Sure, but that can mean anything at all. Adding procedure activation records to a stack, or print requests to a queue, are examples of adding items to collections. POST is equivalent to RPC, even if you phrase it as adding items to collections. The important thing is to make sure your operations are idempotent when they should be...that means with failures as well. There are many other important things, such as clearly documenting for your clients and intermediate services which of your operations are safe, idempotent, cacheable, etc.. The reason REST does well in-the-large (extensibility, integration, disruption, scalability, etc.) is because of the clear, end-to-end understandings about the properties of operations. If you use POST, even in an idempotent manner, you lose a lot of value in-the-large. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Feb 15, 2013, at 1:41 AM, David Barbour dmbarb...@gmail.com wrote: A technique I've seen used (albeit, only once or twice) is to batch updates from multiple connections, and run batches at 20+Hz while there is demand for them. This only requires one connection from the server to its database, and allows you to respond and close each HTTP connection in a predictable amount of time, and allows you to ensure the updates are committed before replying. The limitation of this technique is that you can't have ad-hoc updates, since those would be too difficult to batch consistently and sensibly. It's a bit specialized, but is able to handle a lot of updates. Distributed database engines that do this natively are becoming popular. They are usually referred to as short transaction processing databases and workloads. By forcing all open transactions to commit or rollback several times a second it is possible to guarantee strict serializability in a distributed database if you can package your transactions within that window. There are a few variations on the idea. Traditional transaction processing databases allowed transactions to be open for an unbounded period of time. There are stories passed around among DBAs of zombie transactions that had been open for months or years. For large-scale distributed databases, the cost of coordinating the transaction state is prohibitive and limits the total transaction throughput. Some clever person noticed that if you can strictly bound the transaction length then it makes the distributed transaction problem much simpler. Conveniently, many transaction processing applications can be made to fit within the STP database model. An STP database engine can support orders of magnitude more transaction throughput than a conventional OLTP database. The tradeoff is that the transaction latency is higher. 10-100 milliseconds seems to be the zone where latency is acceptable but you can still fit most transactions into that window. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] POLs for rules. Fuzz testing nile
Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Fri, Feb 15, 2013 at 10:30 AM, John Carlson yottz...@gmail.com wrote: The most valuable part of the POST is the database generated ID. I realize there are other ways to do this--batching the creation of IDs for example. One needs IDs before doing PUTs and GETs. I generally favor associating IDs with paths or domain values. It is also possible to use a timestamp, or counters. Though, for most cases I want 'stable' identifiers that can be deterministically regenerated and associated, so use of timestamps and counters are not my preference. I can easily generate unique IDs client-side if the ID is derived from a little client information or a session ID. If I need unforgeable or unguessable identifiers for security reasons, I can leverage cryptographic hashes or signatures (HMAC or PKI). In any case, there are patterns that avoid need for 'creation' of identifiers via POST or other means. Many of these patterns have existed for a long time, e.g. in more common use back when the filesystem was a primary persistent state resource. (Creation of 'new' filenames is rarely useful, though some claim dubious utility for temp files.) Yes I understand the value of obfuscating IDs for security reasons. I don't really agree with showing any IDs to the user. There is a difference between showing IDs to the human user and exposing IDs to the client application. To which of these are you objecting? The rpc operations you list below seem like good reasons for using post. I would not say they're reasons for using POST. There are more RESTful, idempotent approaches to control printers and similar, such as PUTting a task into a scheduler or tuple space. Don't assume people read your documentation. And don't blame them if they don't. Some people have reading disabilities. You should feel lucky if you have your full capabilities. The people who need to read documentation about how a system works are the people who maintain, extend, or integrate with it. If they're unwilling or unable to do so, they shouldn't have the job in the first place. If you expose your created date as a key, then people might be apt to put collections with their own created dates. You need to test for realism. I don't know enough about your particular application to say how I'd approach creation dates in your case. Without creation of IDs, I don't often see a use for 'created date', but there is some utility for a 'modified date'. As I mentioned above, timestamps are not to my preference for stability reasons. Though they're okay if they're a meaningful part of the domain values, like a calendar or time-series data. If I feared people would use distant past or future creation dates (i.e. if they had some motivation for doing so that could harm me or my product) then I could secure this easily enough and ensure that PUTs for new resources have timestamps accurate to within a few hours of the server's clock. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
I guess what I am asking for is a critic service. For both POLs and uses of POLs. Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote: I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
Thank you. I was not aware of the terminology surrounding this technique or the current work on it. On Fri, Feb 15, 2013 at 10:34 AM, J. Andrew Rogers and...@jarbox.orgwrote: On Feb 15, 2013, at 1:41 AM, David Barbour dmbarb...@gmail.com wrote: A technique I've seen used (albeit, only once or twice) is to batch updates from multiple connections, and run batches at 20+Hz while there is demand for them. This only requires one connection from the server to its database, and allows you to respond and close each HTTP connection in a predictable amount of time, and allows you to ensure the updates are committed before replying. The limitation of this technique is that you can't have ad-hoc updates, since those would be too difficult to batch consistently and sensibly. It's a bit specialized, but is able to handle a lot of updates. Distributed database engines that do this natively are becoming popular. They are usually referred to as short transaction processing databases and workloads. By forcing all open transactions to commit or rollback several times a second it is possible to guarantee strict serializability in a distributed database if you can package your transactions within that window. There are a few variations on the idea. Traditional transaction processing databases allowed transactions to be open for an unbounded period of time. There are stories passed around among DBAs of zombie transactions that had been open for months or years. For large-scale distributed databases, the cost of coordinating the transaction state is prohibitive and limits the total transaction throughput. Some clever person noticed that if you can strictly bound the transaction length then it makes the distributed transaction problem much simpler. Conveniently, many transaction processing applications can be made to fit within the STP database model. An STP database engine can support orders of magnitude more transaction throughput than a conventional OLTP database. The tradeoff is that the transaction latency is higher. 10-100 milliseconds seems to be the zone where latency is acceptable but you can still fit most transactions into that window. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- bringing s-words to a pen fight ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
I think you're missing the point that some people prefer reading code over documentation. If your code is literate and uses common conventions and doesn't surprise the maintainer isn't that a good thing? I recall someone showing me an infinite loop in the linux kernel. He was surprised. So if you're going to do something surprising, then document it next to the code. On Feb 15, 2013 1:33 PM, David Barbour dmbarb...@gmail.com wrote: On Fri, Feb 15, 2013 at 10:30 AM, John Carlson yottz...@gmail.com wrote: The most valuable part of the POST is the database generated ID. I realize there are other ways to do this--batching the creation of IDs for example. One needs IDs before doing PUTs and GETs. I generally favor associating IDs with paths or domain values. It is also possible to use a timestamp, or counters. Though, for most cases I want 'stable' identifiers that can be deterministically regenerated and associated, so use of timestamps and counters are not my preference. I can easily generate unique IDs client-side if the ID is derived from a little client information or a session ID. If I need unforgeable or unguessable identifiers for security reasons, I can leverage cryptographic hashes or signatures (HMAC or PKI). In any case, there are patterns that avoid need for 'creation' of identifiers via POST or other means. Many of these patterns have existed for a long time, e.g. in more common use back when the filesystem was a primary persistent state resource. (Creation of 'new' filenames is rarely useful, though some claim dubious utility for temp files.) Yes I understand the value of obfuscating IDs for security reasons. I don't really agree with showing any IDs to the user. There is a difference between showing IDs to the human user and exposing IDs to the client application. To which of these are you objecting? The rpc operations you list below seem like good reasons for using post. I would not say they're reasons for using POST. There are more RESTful, idempotent approaches to control printers and similar, such as PUTting a task into a scheduler or tuple space. Don't assume people read your documentation. And don't blame them if they don't. Some people have reading disabilities. You should feel lucky if you have your full capabilities. The people who need to read documentation about how a system works are the people who maintain, extend, or integrate with it. If they're unwilling or unable to do so, they shouldn't have the job in the first place. If you expose your created date as a key, then people might be apt to put collections with their own created dates. You need to test for realism. I don't know enough about your particular application to say how I'd approach creation dates in your case. Without creation of IDs, I don't often see a use for 'created date', but there is some utility for a 'modified date'. As I mentioned above, timestamps are not to my preference for stability reasons. Though they're okay if they're a meaningful part of the domain values, like a calendar or time-series data. If I feared people would use distant past or future creation dates (i.e. if they had some motivation for doing so that could harm me or my product) then I could secure this easily enough and ensure that PUTs for new resources have timestamps accurate to within a few hours of the server's clock. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
I am against showing ids to the end user. With rest you can do a get on a collection uri and see all the entry ids. On Feb 15, 2013 1:33 PM, David Barbour dmbarb...@gmail.com wrote: On Fri, Feb 15, 2013 at 10:30 AM, John Carlson yottz...@gmail.com wrote: The most valuable part of the POST is the database generated ID. I realize there are other ways to do this--batching the creation of IDs for example. One needs IDs before doing PUTs and GETs. I generally favor associating IDs with paths or domain values. It is also possible to use a timestamp, or counters. Though, for most cases I want 'stable' identifiers that can be deterministically regenerated and associated, so use of timestamps and counters are not my preference. I can easily generate unique IDs client-side if the ID is derived from a little client information or a session ID. If I need unforgeable or unguessable identifiers for security reasons, I can leverage cryptographic hashes or signatures (HMAC or PKI). In any case, there are patterns that avoid need for 'creation' of identifiers via POST or other means. Many of these patterns have existed for a long time, e.g. in more common use back when the filesystem was a primary persistent state resource. (Creation of 'new' filenames is rarely useful, though some claim dubious utility for temp files.) Yes I understand the value of obfuscating IDs for security reasons. I don't really agree with showing any IDs to the user. There is a difference between showing IDs to the human user and exposing IDs to the client application. To which of these are you objecting? The rpc operations you list below seem like good reasons for using post. I would not say they're reasons for using POST. There are more RESTful, idempotent approaches to control printers and similar, such as PUTting a task into a scheduler or tuple space. Don't assume people read your documentation. And don't blame them if they don't. Some people have reading disabilities. You should feel lucky if you have your full capabilities. The people who need to read documentation about how a system works are the people who maintain, extend, or integrate with it. If they're unwilling or unable to do so, they shouldn't have the job in the first place. If you expose your created date as a key, then people might be apt to put collections with their own created dates. You need to test for realism. I don't know enough about your particular application to say how I'd approach creation dates in your case. Without creation of IDs, I don't often see a use for 'created date', but there is some utility for a 'modified date'. As I mentioned above, timestamps are not to my preference for stability reasons. Though they're okay if they're a meaningful part of the domain values, like a calendar or time-series data. If I feared people would use distant past or future creation dates (i.e. if they had some motivation for doing so that could harm me or my product) then I could secure this easily enough and ensure that PUTs for new resources have timestamps accurate to within a few hours of the server's clock. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
It seems this is not possible without a fitness function. A declarative approach to defining the what of your program would probably go some way towards making the validation of the how possible. BDD (behavior driven development) is the closest approach I have found to this - however the silver bullet of automatic validation from your declared behaviors is far from having been found. On Fri, Feb 15, 2013 at 12:33 PM, John Carlson yottz...@gmail.com wrote: I guess what I am asking for is a critic service. For both POLs and uses of POLs. Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote: I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
Could the fitness function be # of recent users? Any other ideas? On Feb 15, 2013 2:04 PM, shaun gilchrist shaunxc...@gmail.com wrote: It seems this is not possible without a fitness function. A declarative approach to defining the what of your program would probably go some way towards making the validation of the how possible. BDD (behavior driven development) is the closest approach I have found to this - however the silver bullet of automatic validation from your declared behaviors is far from having been found. On Fri, Feb 15, 2013 at 12:33 PM, John Carlson yottz...@gmail.com wrote: I guess what I am asking for is a critic service. For both POLs and uses of POLs. Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote: I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Fri, Feb 15, 2013 at 11:51 AM, John Carlson yottz...@gmail.com wrote: I am against showing ids to the end user. With rest you can do a get on a collection uri and see all the entry ids. A big aspect of REST architectural style is the ability to distribute resource identifiers with other content, and to discover resources by this means. But that doesn't imply the end user needs to see the identifiers. Resource IDs can be associated with presentation data. For example, you regularly GET pages that happen to include IDs of the form: a href=RESOURCE ID GOES HEREHUMAN TEXT GOES HERE/a If you wanted, you could create a browser that doesn't show the resource IDs. (Honestly, it wouldn't take much effort with all the open source browsers available today.) The reason browsers expose resource IDs is that's what the users wanted. Being against showing ids to the end user is just your opinion. Not everyone agrees. I certainly don't. I favor a world where users can usually look under the hood and satisfy their curiosity about how things work. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. Bad code can be written in any language, and even good code can be used to develop bad ideas and architectures. You can't ever ensure good design, not least of all because it's unreasonably difficult to define good. But you can develop POLs that encourage useful features that tend to be part of a good design, i.e. by making the path-of-least-resistance be the right thing, by supporting compositional reasoning and static analysis, by making tests easy to specify and perform. Conversational or self-explaining computations can make documentation more interactive. All this is also true of general purpose programming. Though, when you have problem-specific languages you can usually achieve a much higher degree of composition. (E.g. it's easier to compose graphics than to compose arbitrary subprograms.) Probabilistic languages certainly have a lot of utility at the human-computer interface - not only for text commands, but for use of voice or gesture. (There is an augmented-programming google group that's interested in such possibilities. The notion of 'live programming' tends to bridge the gap with HCI.) On Fri, Feb 15, 2013 at 11:33 AM, John Carlson yottz...@gmail.com wrote: I guess what I am asking for is a critic service. For both POLs and uses of POLs. Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote: I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- bringing s-words to a pen fight ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
We have design guidelines. We have look and feel. The cell phone seems to narrow down what is possible, pushing developers towards common metaphors. There are app creation wizards for smartphones now. I think there may be a turning point where people may start using wizards to create more apps. I sort of view a wizard as a front end for a POL. If the app is constructed from well known components it would seem easier to validate. Reducing the kloc as Alan suggests may also make it easier. On Feb 15, 2013 2:04 PM, shaun gilchrist shaunxc...@gmail.com wrote: It seems this is not possible without a fitness function. A declarative approach to defining the what of your program would probably go some way towards making the validation of the how possible. BDD (behavior driven development) is the closest approach I have found to this - however the silver bullet of automatic validation from your declared behaviors is far from having been found. On Fri, Feb 15, 2013 at 12:33 PM, John Carlson yottz...@gmail.com wrote: I guess what I am asking for is a critic service. For both POLs and uses of POLs. Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote: I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
I know a lot of programs collect usage statistics. Does # of times used mean popular, good, or something that needs to be automated? I see your point. We don't want to automate the back button yet. On Feb 15, 2013 2:52 PM, David Barbour dmbarb...@gmail.com wrote: Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. Bad code can be written in any language, and even good code can be used to develop bad ideas and architectures. You can't ever ensure good design, not least of all because it's unreasonably difficult to define good. But you can develop POLs that encourage useful features that tend to be part of a good design, i.e. by making the path-of-least-resistance be the right thing, by supporting compositional reasoning and static analysis, by making tests easy to specify and perform. Conversational or self-explaining computations can make documentation more interactive. All this is also true of general purpose programming. Though, when you have problem-specific languages you can usually achieve a much higher degree of composition. (E.g. it's easier to compose graphics than to compose arbitrary subprograms.) Probabilistic languages certainly have a lot of utility at the human-computer interface - not only for text commands, but for use of voice or gesture. (There is an augmented-programming google group that's interested in such possibilities. The notion of 'live programming' tends to bridge the gap with HCI.) On Fri, Feb 15, 2013 at 11:33 AM, John Carlson yottz...@gmail.com wrote: I guess what I am asking for is a critic service. For both POLs and uses of POLs. Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote: I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- bringing s-words to a pen fight ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Design of web, POLs for rules. Fuzz testing nile
On Feb 15, 2013, at 1:31 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: As a practical matter, most people that use REST use JSON or XML and most people that don't use JSON and XML also don't use REST for related reasons. But it is not fair to blame REST for what is primarily an issue with JSON and XML even though they are often seen together. REST is not efficient but it usually pretty low on the long list of things that are slowing down an application. I'm not sure I completely agree with you here. There are an awful lot of RESTful interfaces to things like imagery and map databases. What makes them restful is how data is addressed (by URL), and the use of HTTP operations to GET/PUT/DELETE data, but the actual data formats are content specific (audio formats, video formats, shape files, etc.) Sure, I did not mean to imply that REST is all JSON/XML content, just that in practice the majority of it tends to be and that much of the slowness people associate with REST architectures can be laid at the feet of parsing JSON/XML content rather than REST. I've certainly built REST architectures that heaved vast quantities of binary imagery over the 'net. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
Could one analyze the test code (not the main source code) assuming it is complete enough and make a determination? That is, the style of testing determines how good the main code is. Is there behavior driven development for behavior driven development? On Feb 15, 2013 2:04 PM, shaun gilchrist shaunxc...@gmail.com wrote: It seems this is not possible without a fitness function. A declarative approach to defining the what of your program would probably go some way towards making the validation of the how possible. BDD (behavior driven development) is the closest approach I have found to this - however the silver bullet of automatic validation from your declared behaviors is far from having been found. On Fri, Feb 15, 2013 at 12:33 PM, John Carlson yottz...@gmail.com wrote: I guess what I am asking for is a critic service. For both POLs and uses of POLs. Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote: I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
I.e.: given new code is checked in When code coverage is complete And all tests succeed Then deploy to integration On Feb 15, 2013 3:30 PM, John Carlson yottz...@gmail.com wrote: Could one analyze the test code (not the main source code) assuming it is complete enough and make a determination? That is, the style of testing determines how good the main code is. Is there behavior driven development for behavior driven development? On Feb 15, 2013 2:04 PM, shaun gilchrist shaunxc...@gmail.com wrote: It seems this is not possible without a fitness function. A declarative approach to defining the what of your program would probably go some way towards making the validation of the how possible. BDD (behavior driven development) is the closest approach I have found to this - however the silver bullet of automatic validation from your declared behaviors is far from having been found. On Fri, Feb 15, 2013 at 12:33 PM, John Carlson yottz...@gmail.comwrote: I guess what I am asking for is a critic service. For both POLs and uses of POLs. Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote: I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] POLs for rules. Fuzz testing nile
There are people who do this sort of continuous deployment, and even swear by it. I've not tried it, but I suppose it encourages development of good tests and easily speeds up the feedback cycle. I've been thinking about such approaches for Wiki-based development. On Fri, Feb 15, 2013 at 2:04 PM, John Carlson yottz...@gmail.com wrote: I.e.: given new code is checked in When code coverage is complete And all tests succeed Then deploy to integration On Feb 15, 2013 3:30 PM, John Carlson yottz...@gmail.com wrote: Could one analyze the test code (not the main source code) assuming it is complete enough and make a determination? That is, the style of testing determines how good the main code is. Is there behavior driven development for behavior driven development? On Feb 15, 2013 2:04 PM, shaun gilchrist shaunxc...@gmail.com wrote: It seems this is not possible without a fitness function. A declarative approach to defining the what of your program would probably go some way towards making the validation of the how possible. BDD (behavior driven development) is the closest approach I have found to this - however the silver bullet of automatic validation from your declared behaviors is far from having been found. On Fri, Feb 15, 2013 at 12:33 PM, John Carlson yottz...@gmail.comwrote: I guess what I am asking for is a critic service. For both POLs and uses of POLs. Can POLs be designed such that uses of POLs ensure good design? Good architecture? I am way beyond my technical knowledge here. On Feb 15, 2013 1:19 PM, John Carlson yottz...@gmail.com wrote: I know of a few sites/tools which critcise your wesite...is there one for css? On Feb 15, 2013 1:02 PM, John Carlson yottz...@gmail.com wrote: Sorry we got into a big discussion about the web. I really want to discuss POLs for rules, css being one of them. And in particular, once we have a good POL, how to test it, and author with it--how to create a great POL program? But what about probablistic rules? Can we design an ultimate website w/o a designer? Can we use statistics to create a great solitaire player--i have a pretty good stochastic solitaire player for one version of solitaire...how about others? How does one create a great set of rules? One can create great rule POLs, but where are the authors? Something like cameron browne's thesis seems great for grid games. He is quite prolific. Can we apply the same logic to card games? Web sites? We have The Nature of Order by c. Alexander. Are there nile designers or fuzz testers/genetic algorithms for nile? Is fuzz testing a by product of nile design...should it be? If you want to check out the state of the art for dungeons and dragons POLs check out fantasy grounds...xml hell. We can do better. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- bringing s-words to a pen fight ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
