In a previous post I mentioned the behavior of NK's URI resolution as being a DOS vs. Unix kind of behavior (http://www.1060.org/forum/topic/385/1).

Respectfully submitted:

I would submit that a URI should have any nested URIs resolved prior to calling an accessor as it would appear that all accessors have to check all of their arguments as they may, at any time, represent nested URIs. If all accessors that expect arguments have to handle that then there will be an incredible amount of duplicate code spread amongst the accessors that may be better off living in the NK URI resolver.

Is it possible that someone will use a nested URI that will return something other than a string or a binary stream? I suppose, but whether NK handles it or the accessor doesn't change the fact that someone has to handle it and burdening the accessor is going to lead to a duplication of behavior/code that should be avoided...not to mention make life easier for accessor writers (I admit it: I want accessors to be easier to write. NK has a lot of boilerplate code. Users of Spring probably see opportunities to create Spring-based NK convenience classes).

Sorry, just changed the title. Why can't we edit our posts once we submit them?

;)

Carlos,

It is important to understand that in the resource oriented computing abstraction the logical address is not interpreted until it is given to the resolved endpoint.

Here are some examples of logical addresses:

ffcpl:/resources/programs/myprogram.bsh
445-00-0073
914-337-0985
978-0890420256

(Those are a URI, SSN, telephone number in the US and ISBN-13)

These are all valid logical addresses in the context of a ROC system.

As you know, NetKernel currently supports only URI addresses. When one observes a limited set of address patterns it may be tempting to look to the microkernel to provide some interpretation of the URI in order to make the coding of accessors easier. However, this would violate the abstraction.

The NetKernel Foundation API (NKF) does provide some assistance to endpoint developers above the microkernel and within the context of supporting URI address processing. An endpoint that receives a URI address may ask NKF to parse the URI as an active: scheme URI and provide ways to get at the parameter information encoded in the active: scheme. This is why you can code:

context.getRequest().getArgument("operand");

Instead of having to do this:

context.getRequest().getURI();

and parse the logical address yourself.

Even with this assistance, it is important that the accessor interprets the URI and determines if any sub-requests should be issued. For example, with this URI:

active:mapper+operand@ffcpl:/myURI

how can the microkernel know whether the mapper is going to read the operand URI and map it to another URI or simply issue a sub-request for that URI? It can't and it shouldn't.

Regarding your point about code that you see replicating across your accessors, you could refactor that into an abstract class.

-- Randy

Editing of posts is disallowed to preserve historical integrity and avoid "grandfather paradox" situations in threads. Posts can be deleted at the discretion of a moderator.

Please see my response to the above mentioned thread:

http://www.1060.org/forum/entry/1441

It is critical to understand that handling of nested URIs does not cause a proliferation of code boilerplate or otherwise.

However I'm intrigued by your comment "NK has a lot of boilerplate code". Can you explain where you see this code and give an example.

Cheers,
Tony

[Carlos wrote:] Respectfully submitted: I would submit that a URI should have any nested URIs resolved prior to calling an accessor as it would appear that all accessors have to check all of their arguments as they may, at any time, represent nested URIs

Carlos,

I selected this fragment from your posting because I think it may represent a specific locus of confusion. The arguments to an accessor are ALWAYS URIs; there is no other choice. A valid URI is composed ONLY of other URIs, there is NO OTHER DATA TYPE; there are no literal integers, no literal strings, and no variable names to be resolved. So, for example the URI:

active:concat+arg1@ffcpl:/uri/hello+arg2@ffcpl:/uri/world

is composed of/from 3 other URIs:

active:concat ffcpl:/uri/hello ffcpl:/uri/world

What's trickier, however, is that your (proposed) URI:

active:myImageCrop+image@MyImage.jpg+x@100+y@100+width@50+height@50

is also composed of/from 6 other URIs. (They may look like string literals and integer literals but they are not):

active:myImageCrop MyImage.jpg 100 100 50 50

Note that the last 5 of these do not follow the valid syntax for a URI scheme but NetKernel will try to resolve them anyway [Aside: I understand why NK does this, but I have always felt that it is a major mistake: a "special case" in the rules which creates tremendous confusion. If a URI has invalid syntax, it should cause an error]. The resolution of these ill-formed URIs is then dependent of the particular rewrite rules for the module but, often, they end up being translated into something like this:

ffcpl:/scripts/MyImage.jpg ffcpl:/resources/1

Note that the absence of literal strings in URIs is why you have to use the data: URI scheme to pass literal values.

It is important to remember that URIs are references (pointers) to some data item. This is analogous to writing programs in C which accept ONLY pointers to data. The receiving C function can choose to dereference the pointer to get the actual data or it can perform very limited operations on the pointer itself. By analogy, your NK accessor will usually "dereference" the URI (by sourcing or transrepting) to retrieve and process the data which the URI "points to". But, your accessor may also choose to view the URI as a Java String and/or to pass the URI on to sub-requests.

Finally, I've found that it is helpful to NOT think of creating and manipulating URIs as "programming" since that often sets up misconceptions. Anyway, I hope that some of this helps you to better understand and use NK.
    regards,
    -tom

[/quote]