[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Jonathan Borden" <jborden@mediaone.net>
> 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.
|
