Cart
[Home] [By Thread] [By Date] [Recent Entries]
----- Original Message ----- From: "Jonathan Borden" <jborden@m...> > What does what I am doing with RDDL have to do with what you are saying? You > started this discussion. To quote you: > > "This wins with no question, I think. And I think > the buzzword should be not RDF, but RDDL > ( not the current version, sorry ;-( ). " > > So what is the future version? What are you talking about. You say you have > explained yourself but I still have no idea what you are talking about. You > have trouble explaining yourself in words, so explain yourself in another > way, code, a formula, you pick. 1. I belive that earlier or later, computers will communicate on the Internet. 2. I belive that some part of their communication would be based on fetching some semantics knowledge about the 'tag' ( or 'namespace' ), and something like RDDL 'dispatchers' attached to the URLs could be used for that. 3. Because current RDDL service is attached to namespaces URL with 1-1 mapping ( by historical purposes ) this means that to use the service, the computer, which is hosting RDDL semantics *no*matter* what is the semantics of RDDL - should always be up and running. If DNS would be based on RDDL's design, Internet would not work. Current RDDL would not work. That's the simplest way to explain myself, not talking about the RDDL itself ( that was not my idea, I was enforced to answer particular questions and forgot to tell it loud and verbose that current RDDL would not work anyway, no matter what happens serverside ). 4. Because current RDDL would not work and because it calles 'purposes' 'arclines', I have spent some time desiging the scalable distributed framework that would work and would not call 'purposes' - 'arclines'. I have it designed and it is relatively trivial to implement. Caching, certification and other stuff that I already mentioned, but I was not sure if I need to discuss that, because: a. These issues are pretty much irrelevant to current RDDL. b. This kind of discussion would imply some experience in implementing robust systems ( and I have no idea about your or others background in this area, that's why I just mentioned those areas briefly. However, I think that for example, Gavin or Len had no poblem understanding what I'm talking about). DNS and FidoNet should be telling, actually. I can elaborate, but I'm tired being the only one who elaborates and you are igoring the only question I have. Not good. c. I don't yet undersand what to do with that RDDL. 5. The biggest question I have is : "When/if I implement it - what I will use it for so that it would make sense *right now* ?" And I still have no answer to this question and nobody provided the answer. And I should stress out that I have asked *you* what is the application you plan to use 'RDDL' for and I got no answer. I can ask the same question again. And I'm asking it. Could you please tell me what is the application that you plan to use RDDL for? Before understanding that, I see no point in any discussions of RDDL. > > I think that when questioning my abilities to write > > a (trivial) bunch of code ( that's the 'constructive' > > content of two of your letters ) - you overreact. > > If it is trivial, then let's see it. I ask this only because I just can't > understand your text. Perhaps you are better at explaining yourself in code? > I am not questioning your ability to code, rather your ability to explain > yourself. I think I explained myself pretty clearly. 1. RDDL would not work. 2. I have slightly better design. 3. I don't understand how can I ( or any other person ) possibly use RDDL for purposes other than political, would it be RDDL 1 or RDDL 2 and I don't like writing code that nobody ( including myself ) needs. ( See it all in a letter #2 ) Rgds.Paul. PS. It should not be surprising that in this letter I'm ( as usual ) repeating my previous letters, just slightly expanding some of the words. I think that next letter from myself would be just a list of URLs to previous letters that I've written on this subject.
|
