have a new project I'm trying to do in lisp, as opposed to Java,
although Java seems
already more able to do the underlying behaviors:
Has anyone written the code to do the equivalent behaviors of Java's
"reggie", "mahalo",
"outrigger", etc., i.e., all the JINI stuff? if so, can you give it
away?
my new project is going to be an asynchronous collaborative tool, at the
moment I think
I want something what JINI does (maybe I don't, but if I end up having
to write it in
Java, that's what I'll have to use).
my current plan is that:
user-A initiates something, does some work, "sends it" [I don't know
what that means, yet]
to whoever. users B & C receive the work sometime later, do some more,
maybe what
they've done has to go back to A, be merged...
etc for any number of "users", until the work is done.
it's aimed at being a planning tool, but there's no specific requirement
that it only be for
planning, it's really a data-constructor.
why I need/want JINI behaviors: I want it to be the case that no user's
app has to know about
where/when the other users are logged in.
in some larger sense, I want it to behave like comm packet routers, in
that (unlike JINI) the
users can be spread over a wide area (where JINI cannot, because it uses
multicast packets
in the discovery steps, and multicast packets don't generally pass
through routers--which lead
to a debug hassle earlier this month that I wasn't able to solve, as I
am remote from some
folks I was trying to integrate with).
while I think I can do so, I would prefer not to reimplement these
things if i don't have to...I
have the feeling my boss would not be happy about it, unless I can show
that I can do it
in a matter of hours...
on that note: in ACL 5, how does a client send a multicast packet? how
does a server
receive it? how does a server respond? how does a client collect
responses? (thinking of the JINI
process of discovery, where a client program wish to register its
existence, calls out to all registry
servers, get a response from them all, and needs to keep track of them,
to unregister later)
please reply direct to ·····@bbn.com, i'm not blessed with enough to
time to read news
like I used to be...or send to ·····@cox.rr.com in case the bbn address
times out, my email
there is down right now...
-- clint hyde, bbn, 15-year lisper, and one-time Explorer LispM
expert...
click on <a href="http://phaedrus.gteinetva.bbnplanet.net/">TRS
downloads</a> to see where
I'll be putting Lisp source for various things. only one item there now,
an XML viewing/
parsing/manipulation tool, based on Sam Steingold's XML parser code. i
modified it to fix some
bugs, and to work cleanly and efficiently with the CLIM gui code. you
can load most any xml, so
long as it is "well-formed" (i.e., no tags like this: <foo/>), it will
use entities. the visual presentation
uses CLIM's "format-graph-from-roots", so it draws that very nice
tree-graph (unlike Java's
JTree, which bites). there's an example xml file in there.
at some point I'll put a number of other things out there. probably just
as source rather than as an
executable image like the xml-viewer is.
Clinton Hyde <·····@bbn.com> writes:
> why I need/want JINI behaviors: I want it to be the case that no user's
> app has to know about
> where/when the other users are logged in.
hey, sounds like SMTP....
--
(espen)
agreed, there is a mail-like flavor to this, and in fact I imagine that I
need a two-level
behavior, where email is the fall-back. but I think that there is a more
immediate
delivery mode where the data goes into its own window if user-A is in fact
logged
in someplace...
with JINI, when you register, the registry knows where you are, and you can
discover from the registry where other services come from. I'd like to use
something
like this as the primary connection, but when someone is not logged in, I'd
like the
result to be that the delivered data goes to that person's email address as
an attachment
Espen Vestre wrote:
> Clinton Hyde <·····@bbn.com> writes:
>
> > why I need/want JINI behaviors: I want it to be the case that no user's
> > app has to know about
> > where/when the other users are logged in.
>
> hey, sounds like SMTP....
>
> --
> (espen)
--
please reply direct to <a ··················@bbn.com">Clint Hyde</a>
I don't have enough time to scan everything I'd like to, and don't
want to miss your answers...
-- clint
* Clinton Hyde <·····@bbn.com>
| agreed, there is a mail-like flavor to this, and in fact I imagine
| that I need a two-level behavior, where email is the fall-back. but
| I think that there is a more immediate delivery mode where the data
| goes into its own window if user-A is in fact logged in someplace...
Please read RFC 821 and look for SEND, SOML and SAML.
Please also don't break your lines manually. Your newsreader does
that for you at a different point in the line than you do, and the
result is quite horrible.
#:Erik
--
If this is not what you expected, please alter your expectations.
Clinton Hyde wrote:
> agreed, there is a mail-like flavor to this, and in fact I imagine that I
> need a two-level
> behavior, where email is the fall-back. but I think that there is a more
> immediate
> delivery mode where the data goes into its own window if user-A is in fact
> logged
> in someplace...
>
> with JINI, when you register, the registry knows where you are, and you
can
> discover from the registry where other services come from. I'd like to use
> something
> like this as the primary connection, but when someone is not logged in,
I'd
> like the
> result to be that the delivered data goes to that person's email address
as
> an attachment
I think Email would be really the way to go. You can deliver Email
reasonably fast if you have a quick MTA (possibly your own MTA on your own
machine?).
Your clients can receive the Messages by polling a specific POP3 account.
It would be a good idea to filter out invalid messages on that account.
You can use ElGamal and SHA to sign,authenticate and encrypt all messages.
Using broadcast delivery of IP-Packets won't be a good idea because there
are not very much OS' that come with good support for this.
Using this features could also lead to problems with firewalls.
Most people would not have any use of such a tool because they work in
a LAN that has very limited access to the internet.
(And Groupware that is limited to a LAN isn't worth a penny)
--
Jochen Schmidt
···@dataheaven.de
http://www.dataheaven.de
Jochen Schmidt wrote:
> Clinton Hyde wrote:
>
> > agreed, there is a mail-like flavor to this, and in fact I imagine that I
> need a two-level
> > behavior, where email is the fall-back. but I think that there is a more
> immediate
> > delivery mode where the data goes into its own window if user-A is in fact
> > logged in someplace...
> >
> > with JINI, when you register, the registry knows where you are, and you can
> > discover from the registry where other services come from. I'd like to use
> > something like this as the primary connection, but when someone is not
> logged in,
> I'd like the
> > result to be that the delivered data goes to that person's email address as
> > an attachment
>
> I think Email would be really the way to go. You can deliver Email
> reasonably fast if you have a quick MTA (possibly your own MTA on your own
> machine?).
> Your clients can receive the Messages by polling a specific POP3 account.
> It would be a good idea to filter out invalid messages on that account.
> You can use ElGamal and SHA to sign, authenticate and encrypt all messages.
> Using broadcast delivery of IP-Packets won't be a good idea because there
> are not very much OS' that come with good support for this.
> Using this features could also lead to problems with firewalls.
> Most people would not have any use of such a tool because they work in
> a LAN that has very limited access to the internet.
> (And Groupware that is limited to a LAN isn't worth a penny)
>
> --
> Jochen Schmidt
> ···@dataheaven.de
> http://www.dataheaven.de
that misses what JINI is about--the book says right up front that it uses
multicast packets, and that probably isn't going to make it too far outside your
local net, possibly not even through the first router...which is fine, and is
the reason I said I'm thinking about how packets get routed over WANs, where the
distributed DNS mechanism dynamically learns about new machines, but I don't
know the details...
further info: multicast is NOT used to deliver data, it's only used in the
service-discovery phase, when your app starts up and announces itself to the
world--you multicast to get to the registry(ies), and then you don't multicast
again. which is fine, reasonable behavior--yr sys-admins would get in a snit if
you were multicasting a lot.
and to an extent I'm still SWAGging this entire system concept, because I don't
yet know what real usage I'm aiming at...I just don't think I want email as the
primary transport. not that it couldn't be, figure that my data passes as an
attachment, a new mime-type, you can dbl-click it when you get one and up comes
my app
-- clint