Loading ...
Sorry, an error occurred while loading the content.

Re: Mobility Architecture -- feedback

Expand Messages
  • McMeikan, Andrew
    One thing that is not covered is P2P with mobile devices, you seem more focused on client/server. It would be nice to have a device that can oppourtunisticaly
    Message 1 of 6 , Sep 2 6:31 PM
    • 0 Attachment
      One thing that is not covered is P2P with mobile devices, you seem more
      focused on client/server.

      It would be nice to have a device that can oppourtunisticaly network with
      other devices providing a communication system that while slow should
      provide a close to zero cost for message delivery.

      Such a system would only be useful where the messages are not critical yet
      where persistant contact paths exist its convienience and non-reliance on
      infrastructure would be beneficial.

      Protocol would be of the form 'if you see person x let them know y', hashes
      of short messages and their destination could be broadcast with recievers
      checking the destination against previous contact paths. If free space
      allows the reciever could request the message on a best try basis. As
      storage and unit use densities increase this method will work better.

      cya, Andrew...

      > Date: Tue, 31 Aug 2004 19:30:20 -0700
      > From: Johannes Ernst <jernst@...>
      > Subject: Re: Mobility Architecture -- feedback?
      >
      > Decentralizers,
      >
      > based on the server logs, I think quite a few of you seem to have
      > looked at this paper since we posted it.
      >
      > But the feedback has been, shall we say, sparse. This is one of the
      > highest-IQ mailing lists that I am aware of anywhere, with lots of
      > people who have related experience (and opinions!). After
      > all, mobile
      > user behavior is about as decentralized as it gets -- and how to
      > support such decentralized behavior is one of the core challenges of
      > mobile software technology in my view.
      >
      > What can we do to challenge you so you will send e-mail and disagree
      > with us on this paper? ;-)
      >
      > We are sincerely interested in your positive and negative
      > feedback. Can
      > we get some more?
      >
      > The URL again:
      > http://netmesh.info/blog/NetMesh/Mobility-Architecture-Require
      > ments.html
      >
      >
      > Cheers,
      >
      >
      >
      > Johannes.
      >
      >

      This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
    • Axel Peter Mustad
      Some mobile network providers offer services enabling users (x) to receive short messages from the network operator about where friends of x (y) are localized
      Message 2 of 6 , Sep 3 12:18 AM
      • 0 Attachment
        Some mobile network providers offer services enabling users (x) to
        receive short messages from the network operator about where friends of
        x (y) are localized (if y beforehand accepted x being a friend). On the
        contrary, Motorola offered a few years back an integrated service in
        one of its mobilephone models, where users (x and y) where able
        (limited to a certain geographical range) to communicate using the
        mobile phone in a way similar as one uses walkie-talkies (private
        network). Now, if one combined such two services one would have P2P
        mobile phone systems as suggested below. To legitimize implementation
        of said combined service on a global scale, you could try to partner
        with a company Flextronis...

        Best wishes, Axel


        On Sep 3, 2004, at 3:31 AM, McMeikan, Andrew wrote:

        > One thing that is not covered is P2P with mobile devices, you seem more
        > focused on client/server.
        >
        > It would be nice to have a device that can oppourtunisticaly network
        > with
        > other devices providing a communication system that while slow should
        > provide a close to zero cost for message delivery.
        >
        > Such a system would only be useful where the messages are not critical
        > yet
        > where persistant contact paths exist its convienience and non-reliance
        > on
        > infrastructure would be beneficial.
        >
        > Protocol would be of the form 'if you see person x let them know y',
        > hashes
        > of short messages and their destination could be broadcast with
        > recievers
        > checking the destination against previous contact paths. If free space
        > allows the reciever could request the message on a best try basis. As
        > storage and unit use densities increase this method will work better.
        >
        > cya, Andrew...
        >
        >> Date: Tue, 31 Aug 2004 19:30:20 -0700
        >> From: Johannes Ernst <jernst@...>
        >> Subject: Re: Mobility Architecture -- feedback?
        >>
        >> Decentralizers,
        >>
        >> based on the server logs, I think quite a few of you seem to have
        >> looked at this paper since we posted it.
        >>
        >> But the feedback has been, shall we say, sparse. This is one of the
        >> highest-IQ mailing lists that I am aware of anywhere, with lots of
        >> people who have related experience (and opinions!). After
        >> all, mobile
        >> user behavior is about as decentralized as it gets -- and how to
        >> support such decentralized behavior is one of the core challenges of
        >> mobile software technology in my view.
        >>
        >> What can we do to challenge you so you will send e-mail and disagree
        >> with us on this paper? ;-)
        >>
        >> We are sincerely interested in your positive and negative
        >> feedback. Can
        >> we get some more?
        >>
        >> The URL again:
        >> http://netmesh.info/blog/NetMesh/Mobility-Architecture-Require
        >> ments.html
        >>
        >>
        >> Cheers,
        >>
        >>
        >>
        >> Johannes.
        >>
        >>
        >
        > This e-mail and any attachment is for authorised use by the intended
        > recipient(s) only. It may contain proprietary material, confidential
        > information and/or be subject to legal privilege. It should not be
        > copied, disclosed to, retained or used by, any other party. If you are
        > not an intended recipient then please promptly delete this e-mail and
        > any attachment and all copies and inform the sender. Thank you.
        >
        >
        > Announce or discover P2P conferences on the P2P Conference Wiki at
        > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferenceshe
        > P2P Conference Wiki at
        > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
      • Johannes Ernst
        Andrew, thanks for your comments. I knew some people on this list would have something to say ;-) ... Hmm, I m not sure I see that. Do I misunderstand you? [We
        Message 3 of 6 , Sep 4 9:44 PM
        • 0 Attachment
          Andrew, thanks for your comments. I knew some people on this list would
          have something to say ;-)

          > One thing that is not covered is P2P with mobile devices, you seem more
          > focused on client/server.

          Hmm, I'm not sure I see that. Do I misunderstand you?

          [We have a specific section in there titled "Enables decentralized
          development, deployment and operation", which I'd think of as some of
          the core characteristics of P2P software. It also explicitly asks for
          P2P support in "Supports a large variety of types of software". And
          under "Federatability" we say it would desirable that: "Many parts of
          the architecture can developed, deployed, operated and maintained by
          many different individuals and organizations. This is the opposite of
          requiring a centralized entity that is responsible for all aspects of
          the system."]

          Note: this is requirements doc, not a solutions doc.

          > It would be nice to have a device that can oppourtunisticaly network
          > with
          > other devices providing a communication system that while slow should
          > provide a close to zero cost for message delivery.

          I take this as you are asking for mesh networking support?

          I'll add that ... good point.

          > Such a system would only be useful where the messages are not critical
          > yet
          > where persistant contact paths exist its convienience and non-reliance
          > on
          > infrastructure would be beneficial.
          >
          > Protocol would be of the form 'if you see person x let them know y',
          > hashes
          > of short messages and their destination could be broadcast with
          > recievers
          > checking the destination against previous contact paths. If free space
          > allows the reciever could request the message on a best try basis. As
          > storage and unit use densities increase this method will work better.
          >
          > cya, Andrew...
          >
          >> Date: Tue, 31 Aug 2004 19:30:20 -0700
          >> From: Johannes Ernst <jernst@...>
          >> Subject: Re: Mobility Architecture -- feedback?
          >>
          >> Decentralizers,
          >>
          >> based on the server logs, I think quite a few of you seem to have
          >> looked at this paper since we posted it.
          >>
          >> But the feedback has been, shall we say, sparse. This is one of the
          >> highest-IQ mailing lists that I am aware of anywhere, with lots of
          >> people who have related experience (and opinions!). After
          >> all, mobile
          >> user behavior is about as decentralized as it gets -- and how to
          >> support such decentralized behavior is one of the core challenges of
          >> mobile software technology in my view.
          >>
          >> What can we do to challenge you so you will send e-mail and disagree
          >> with us on this paper? ;-)
          >>
          >> We are sincerely interested in your positive and negative
          >> feedback. Can
          >> we get some more?
          >>
          >> The URL again:
          >> http://netmesh.info/blog/NetMesh/Mobility-Architecture-Require
          >> ments.html
          >>
          >>
          >> Cheers,
          >>
          >>
          >>
          >> Johannes.
          >>
          >>
          >
          > This e-mail and any attachment is for authorised use by the intended
          > recipient(s) only. It may contain proprietary material, confidential
          > information and/or be subject to legal privilege. It should not be
          > copied, disclosed to, retained or used by, any other party. If you are
          > not an intended recipient then please promptly delete this e-mail and
          > any attachment and all copies and inform the sender. Thank you.
          >
        • Johannes Ernst
          There s actually a range of new things showing up on the market. From push-to-talk, over friend-finder, to mesh networking and, yes, bluejacking. Vodafone has
          Message 4 of 6 , Sep 4 10:11 PM
          • 0 Attachment
            There's actually a range of new things showing up on the market. From
            push-to-talk, over friend-finder, to mesh networking and, yes,
            bluejacking. Vodafone has some interesting "slideware" (pardon-me,
            Flash-ware) on their website as well. Intel Research in Berkeley does
            interesting stuff as well (blogged about it at
            http://netmesh.info/blog/Related%20Writings/intel-research-street-
            talk.html)

            What interests us (Joaquin and me) most is what impact these emerging
            layers in the networking/communications stack have on software
            architecture. E.g. the process of "create JAR, identify JDBC data
            source, put on app server" does not really work any more ... so what
            are the requirements that impact what the "new" architecture needs to
            be?

            On Sep 3, 2004, at 0:18, Axel Peter Mustad wrote:

            > Some mobile network providers offer services enabling users (x) to
            > receive short messages from the network operator about where friends of
            > x (y) are localized (if y beforehand accepted x being a friend). On the
            > contrary, Motorola offered a few years back an integrated service in
            > one of its mobilephone models, where users (x and y) where able
            > (limited to a certain geographical range) to communicate using the
            > mobile phone in a way similar as one uses walkie-talkies (private
            > network). Now, if one combined such two services one would have P2P
            > mobile phone systems as suggested below. To legitimize implementation
            > of said combined service on a global scale, you could try to partner
            > with a company Flextronis...
            >
            > Best wishes, Axel
            >
            >
            > On Sep 3, 2004, at 3:31 AM, McMeikan, Andrew wrote:
            >
            >> One thing that is not covered is P2P with mobile devices, you seem
            >> more
            >> focused on client/server.
            >>
            >> It would be nice to have a device that can oppourtunisticaly network
            >> with
            >> other devices providing a communication system that while slow should
            >> provide a close to zero cost for message delivery.
            >>
            >> Such a system would only be useful where the messages are not critical
            >> yet
            >> where persistant contact paths exist its convienience and non-reliance
            >> on
            >> infrastructure would be beneficial.
            >>
            >> Protocol would be of the form 'if you see person x let them know y',
            >> hashes
            >> of short messages and their destination could be broadcast with
            >> recievers
            >> checking the destination against previous contact paths. If free
            >> space
            >> allows the reciever could request the message on a best try basis. As
            >> storage and unit use densities increase this method will work better.
            >>
            >> cya, Andrew...
            >>
            >>> Date: Tue, 31 Aug 2004 19:30:20 -0700
            >>> From: Johannes Ernst <jernst@...>
            >>> Subject: Re: Mobility Architecture -- feedback?
            >>>
            >>> Decentralizers,
            >>>
            >>> based on the server logs, I think quite a few of you seem to have
            >>> looked at this paper since we posted it.
            >>>
            >>> But the feedback has been, shall we say, sparse. This is one of the
            >>> highest-IQ mailing lists that I am aware of anywhere, with lots of
            >>> people who have related experience (and opinions!). After
            >>> all, mobile
            >>> user behavior is about as decentralized as it gets -- and how to
            >>> support such decentralized behavior is one of the core challenges of
            >>> mobile software technology in my view.
            >>>
            >>> What can we do to challenge you so you will send e-mail and disagree
            >>> with us on this paper? ;-)
            >>>
            >>> We are sincerely interested in your positive and negative
            >>> feedback. Can
            >>> we get some more?
            >>>
            >>> The URL again:
            >>> http://netmesh.info/blog/NetMesh/Mobility-Architecture-Require
            >>> ments.html
            >>>
            >>>
            >>> Cheers,
            >>>
            >>>
            >>>
            >>> Johannes.
            >>>
            >>>
            >>
            >> This e-mail and any attachment is for authorised use by the intended
            >> recipient(s) only. It may contain proprietary material, confidential
            >> information and/or be subject to legal privilege. It should not be
            >> copied, disclosed to, retained or used by, any other party. If you are
            >> not an intended recipient then please promptly delete this e-mail and
            >> any attachment and all copies and inform the sender. Thank you.
            >>
            >>
            >> Announce or discover P2P conferences on the P2P Conference Wiki at
            >> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferenceshe
            >> P2P Conference Wiki at
            >> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
            >> Yahoo! Groups Links
            >>
            >>
            >>
            >>
            >>
            >
            >
            >
            > Announce or discover P2P conferences on the P2P Conference Wiki at
            > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferenceshe
            > P2P Conference Wiki at
            > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
          • Lucas Gonze
            ... A thing that I didn t understand from your requirements document is why this needs to change. For myself, I have to say that I despair about a more
            Message 5 of 6 , Sep 5 10:48 AM
            • 0 Attachment
              On Sat, 4 Sep 2004, Johannes Ernst wrote:
              > What interests us (Joaquin and me) most is what impact these emerging
              > layers in the networking/communications stack have on software
              > architecture. E.g. the process of "create JAR, identify JDBC data
              > source, put on app server" does not really work any more ... so what
              > are the requirements that impact what the "new" architecture needs to
              > be?

              A thing that I didn't understand from your requirements document is why
              this needs to change.

              For myself, I have to say that I despair about a more decentralized dev
              stack for mobile apps, at least in the short term.

              - Lucas
            • Johannes Ernst
              Lucas, on your question: there s a gaping hole in the market, which is an understanding what all the bits and pieces are that are needed to truly deploy mobile
              Message 6 of 6 , Sep 6 10:57 PM
              • 0 Attachment
                Lucas, on your question: there's a gaping hole in the market, which is
                an understanding what all the bits and pieces are that are needed to
                truly deploy mobile software. I don't mean deploying the equivalent of
                the biorhythm software on a PC for those of us old enough to recall --
                there was a real "market" for that kind of software at some point in
                the PC's baby years (which is sort of what we have today on mobile
                devices), but "real" mobile software. Before there is shared
                understanding of what those bits and pieces are there is no fixing
                them, and that's what we'd like to help with. (Your complaint about not
                having a decentralized dev stack is another symptom of the malaise I'm
                talking about -- there isn't even a centralized one if our list of
                requirements is in any way correct)

                Users, today, are spending about half a trillion dollars each year
                (yes!) on their mobile phones. But the mobile software market is, well,
                nowhere close. Is it because there is no need for software wherever I
                go with my mobile device? [Personally, I doubt it.] Is it because the
                devices are underpowered? [Opinions on this one may differ, but people
                routinely buy digital cameras with an order of magnitude of more memory
                than comparable phones -- go figure.] We'd like to help this market
                along and hopefully win a slice of the opportunity.

                If you read what most vendors offering technology in this space have to
                say, in our view, it tends to fall woefully short of the full picture.
                (But then, the beauty of having a public requirements document is that
                those very vendors can comment on why they think most of our
                requirements aren't needed). But if our still-growing list of
                requirements is more or less needed -- and the public discourse in
                places like this one supports this -- then at a very minimum, people
                who want to make mobility real, people who want to make investments of
                time, sweat, money, whatever, for whatever reasons, have a (shared)
                point of departure. E.g. research still needed. Products still needed.
                Assumptions that need to be proven. Open interfaces that need to be
                built. Changes to the stack that need to be made. Etc.

                Depending on how much or little input we get, we might change tack and
                just forge ahead ourselves along the lines of "if the rest of the
                market doesn't care what the real requirements are, the better for us,
                commercially". But we'd rather collaborate, we'd rather forge some sort
                of consensus, which better reflects our way of doing business, and the
                opportunity is so large there's enough $$$ and fame and code and
                whatever everyone's motivation is for all of us ... and we might very
                well get there together first ...

                Does this make sense?

                >> What interests us (Joaquin and me) most is what impact these emerging
                >> layers in the networking/communications stack have on software
                >> architecture. E.g. the process of "create JAR, identify JDBC data
                >> source, put on app server" does not really work any more ... so what
                >> are the requirements that impact what the "new" architecture needs to
                >> be?
                >
                > A thing that I didn't understand from your requirements document is why
                > this needs to change.
                >
                > For myself, I have to say that I despair about a more decentralized dev
                > stack for mobile apps, at least in the short term.
              Your message has been successfully submitted and would be delivered to recipients shortly.