AeroDoc Getting Started experience
by Burr Sutter
What follows are my notes for AeroDoc - a challenge demo to get up and running and I have only completed the journey for Android - need some more focused time for iOS. My steps may be incomplete as I was making notes while still fighting through the jungle and getting a few bug fixes from the team along the way - Thank you very much - I will be using this demo a lot next week. Please edit as you see fit - we should clean this up and publish a step by step guide on how to AeroDoc.
Note: the UI of the mobile app is a bit clunky - see screenshots of the login screen below
Getting aerodoc running for Android/GCM with Cordova:
1) Download Unified Push Server - http://aerogear.org/download/
2) Create & deploy a DataSource (see attached) on EAP
3) Drag & drop .war to deployments folder of EAP 6.1
4) Start EAP
5) Login at http://localhost:8080/aerogear-unifiedpush-server-0.8.1/
6) admin and "123"
7) You will be prompted to change the password - make it something you won't forget - I use the same password for EAP admin itself
8) Create a new Push Application
9) Add Variant
10) Google Cloud API: https://code.google.com/apis/console/b/0/?pli=1
follow notes at http://aerogear.org/docs/guides/aerogear-push-android/google-setup/
input your API Key and Project Number (which is the SenderID in the JavaScript codebase later on)
11) Backend web app (also contains the REST endpoints for the AeroDoc app)
git clone https://github.com/aerogear/aerogear-aerodoc-cordova
mvn clean compile package
deploy the .war to the EAP server
note: I had to git clone and "mvn install" the Java Client
https://github.com/aerogear/aerogear-unifiedpush-java-client
as it was a dependency required to build the backend web app
using the browser, hit
http://192.168.1.102:8080/aerodoc
Note: you need to know your IP address later
and make sure to start your EAP with -b 0.0.0.0 or using the
"Listen on all interfaces to allow remote web connections" checkbox in the Server properties of JBDS/JBoss Tools
Login in as "john" with a password of "123"
You can create Leads - basically Doctors who need a phone call one of your sales agents like Maria or Bob.
12) Frontend hybrid mobile app
git clone https://github.com/aerogear/aerogear-aerodoc-cordova
follow the instructions in the read me
update app.js in merges/android
also open and update LoginController.js in merges/android
pushNotification.register(function() {}, function(){}, {"senderID":"492580885002", "ecb":"angular.element($('.topcoat-notification')).scope().onNotification"});
where "senderID" is your Google Project ID from step 10
13) Import the Android app into Eclipse+Android Tools using the File-Import-Android wizard
It will appear as "HelloCordova" inside of the IDE
14) Plug in at least one Android device into your USB - assuming you have setup that device for development (Google for "how to enable developer settings")
http://www.androidcentral.com/how-enable-developer-settings-android-42
15) Using Eclipse, Run As Android Application and target the device.
If the Emulator tries to start, by passing the device, select Run Configurations, select the Target tab and check "Always prompt to pick device", hit Apply and OK
16) The app should install and run on the android device
login with "maria" and "123"
17) Back to http://192.168.1.102:8080/aerodoc
Create a Lead
Dr Sally Mae Thomas
Manhattan
1231231234
and hit Save
click on the Lead, hit the Search Agents button to get a list of sales agents (those folks running the mobile app like Maria in step 16), check the box and hit Send Lead
Note: you should instantly see the new lead appear in the application, along with a red notification that says "A new lead has been created" and if the mobile is in the background it will put up a message in the Android 4 notification bar. Selecting that notification will pop the application back to the foreground.
If the app is not running (you killed/closed it competely), the notification will still appear in the top bar, selection of the notification will re-launch the app, where you can attempt to sign-in as "maria" and "123" but login may fail - just kill the app, restart the app server, restart it from the application tray/home screen. I am not sure why logins just fail at times, recycling the app server helps.
18) If you deploy the app to 2 or more devices (leveraging that prompt for device trick in step 15), you can select the Lead (e.g. Dr Sally Mae Thomas) on the app and then hit the Accept button which will remove the lead from the overall list and send a push notification to all other sales agents (e.g. Bob whose password is also "123") and remove the lead from their list.
10 years, 5 months
Aerogear Security (Picketlink)? enhancements
by Karel Piwko
Hey,
I've integrated Aerogear Security with PicketLink installed as JBoss submodule.
I find following challenges complicating the setup/reducing feature set and I
think they should be addressed:
1/ Aerogear Security Submodule - if you install PL as module and add it as
dependency into jboss-deployment-structure.xml, you need to manually exclude
plenty of PL deps from pom.xml. I think that easiest way how make setup more
convenient would be to create Aerogear Security PL submodule on top
of PL submodule and then easily mark aerogear-security-pickelink as 'provided'
in pom.xml
2/ AuthenticationManager/CredentialsMatcher is limited to (T user,
String password). However, PL allows more ways of authentication [1] and here we
are simply reducing feature set. I think there should be login(T user, C
credentials) operation as well. There could also be just login(T user) and impl
will be responsible to inject/produce/select correct CredentialsHandler.
Let me know your opinions and I can create JIRAs based on outcome.
Thanks,
Karel
[1] http://docs.jboss.org/picketlink/2/latest/reference/html_single/#d5e776
10 years, 5 months
[Unified Push Server] Roles structure & password management
by Sebastien Blanc
Hi,
Start point is this jira https://issues.jboss.org/browse/AGPUSH-282 for
allowing the creation of additional users/developers.
In the current situation we have just one role : "developer" , so the first
question is :
- Should a user with the role "developer" be able to create another user ?
- Should we introduce a "admin" role that can manage users (create, reset
password, delete) ?
- A mix of permissions ? (a developer can create other users but not remove
them nor reset (except its own) password )
>From there the second question regarding password management :
In the current situation, our default user (called "admin" , yeah a bit
confusing :) ) has a temporary password that must be changed the first time
he logs in.
- Do we want to keep this ?
- Shall we move to a script that creates a user(s) ?
- When we add a user through the admin UI, should we provide a password or
should it be generated and changed on first login ?
In other words, I think we must concretely spec out the user management for
the UPS and we could use this thread to discuss that !
10 years, 5 months
November release (was: Re: [Unified Push Server] Roles structure & password management)
by Matthias Wessendorf
There are still discussion going on, and the spec is also not ready, let;s
move these items OUT of the nov. release:
https://issues.jboss.org/browse/AGPUSH-351 (spec)
https://issues.jboss.org/browse/AGPUSH-282 (impl)
-Matthias
On Tue, Nov 5, 2013 at 4:09 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
> What's the plan moving forward here ?
>
> -Matthias
>
>
>
> On Thu, Oct 17, 2013 at 4:17 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
>
>> Well, yes now that you said that :) Security based on Grouping.
>>
>>
>> On Thu, Oct 17, 2013 at 4:15 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>>
>>> you mean grouping ?
>>>
>>>
>>> On Thu, Oct 17, 2013 at 4:13 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Thu, Oct 17, 2013 at 3:44 PM, Matthias Wessendorf <matzew(a)apache.org
>>>> > wrote:
>>>>
>>>>> any corp. org. may want some with just read-only access;
>>>>> The project lead is allowed to update the keys etc, but all the
>>>>> /normal/ developers can just see the IDs/secrets (so that they can use it
>>>>> in their server apps).
>>>>>
>>>>
>>>> This is also an interesting point, at some point don't we want the
>>>> "read" rights limited to a single/set of pushapps or even a level deeper
>>>> based on variants ?
>>>> Maybe in a big company, Bob the slacker intern has read access for his
>>>> supracool push app but also has access to the Public Relation Push App
>>>> keys ...
>>>>
>>>>
>>>>
>>>>> I guess that's not really (at least for me) closely related to a 'test
>>>>> via admin ui' feature
>>>>>
>>>>> -M
>>>>>
>>>>>
>>>>> On Thu, Oct 17, 2013 at 3:39 PM, Corinne Krych <corinnekrych(a)gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Not sure about the role: user.
>>>>>>
>>>>>> What will be the use case for this one?
>>>>>> One use case, I see is if the 'user' is a tester. If we had the
>>>>>> feature to send push notification test via admin UI (as we discussed in [1]
>>>>>> and [2]).
>>>>>>
>>>>>> ++
>>>>>> Corinne
>>>>>> [1]
>>>>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Push-Server-Admin-...
>>>>>> [2] https://issues.jboss.org/browse/AGPUSH-38
>>>>>>
>>>>>> On Oct 17, 2013, at 3:09 PM, Matthias Wessendorf <matzew(a)apache.org>
>>>>>> wrote:
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Oct 17, 2013 at 2:54 PM, Sebastien Blanc <
>>>>>> scm.blanc(a)gmail.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Oct 17, 2013 at 2:35 PM, Lucas Holmquist <
>>>>>> lholmqui(a)redhat.com> wrote:
>>>>>> >
>>>>>> > On Oct 15, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com>
>>>>>> wrote:
>>>>>> >
>>>>>> >> So for the next Unified Push Release (0.9) it would be nice if we
>>>>>> could have some decent User Management, so I'm bumping this thread again.
>>>>>> >> Some existing pointer :
>>>>>> >>
>>>>>> >> - this thread :)
>>>>>> >> - https://issues.jboss.org/browse/AGPUSH-351
>>>>>> >> - https://gist.github.com/sebastienblanc/6547605
>>>>>> >>
>>>>>> >> First point to define is :
>>>>>> >> - What roles do we want ? And what can these Roles do ?
>>>>>> >
>>>>>> > Admin - Can do all things including creating other users
>>>>>> > Developer - can create apps and such. no access to the user
>>>>>> management UI
>>>>>> > User - read only - not sure if this one is needed
>>>>>> > Yes, not sure also but why not ? Could be useful for a monitoring
>>>>>> app/RHQ plugin that just want to retrieve the list of active pushapps ...
>>>>>> >
>>>>>> >
>>>>>> > +1 - I like these three different roles, including their rights
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >> - How can these Roles be created (granted ...)
>>>>>> >> - Design
>>>>>> >
>>>>>> > I think we are still waiting on Hylke for this? not sure
>>>>>> >
>>>>>> >>
>>>>>> >> Seb
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Tue, Sep 17, 2013 at 2:07 PM, Matthias Wessendorf <
>>>>>> matzew(a)apache.org> wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Tue, Sep 17, 2013 at 2:04 PM, Apostolos Emmanouilidis <
>>>>>> aemmanou(a)redhat.com> wrote:
>>>>>> >> Following the discussion on GitHub [1], here are some points to be
>>>>>> >> discussed about the user management flow:
>>>>>> >>
>>>>>> >> - Does it make sense to add a role select field (admin, developer)
>>>>>> on
>>>>>> >> the enrollment page?
>>>>>> >>
>>>>>> >> hrm, and (perhaps later) a section where to define the roles ? I
>>>>>> think it's a good point, but not sure we need all this 'now' :-)
>>>>>> >>
>>>>>> >> - Should we add an additional password field (password
>>>>>> confirmation) on
>>>>>> >> the enrollment page?
>>>>>> >>
>>>>>> >> yeah, would be nice
>>>>>> >>
>>>>>> >> - I think that the current logged in user shouldn't be available
>>>>>> for
>>>>>> >> deletion
>>>>>> >>
>>>>>> >> yep, I agree
>>>>>> >>
>>>>>> >> [1]:
>>>>>> >>
>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server-admin-ui/pull/6
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Fri, 2013-09-13 at 10:15 +0200, Sebastien Blanc wrote:
>>>>>> >> > A Jira has been created
>>>>>> https://issues.jboss.org/browse/AGPUSH-351
>>>>>> >> > And draft structure has been created
>>>>>> >> > here https://gist.github.com/sebastienblanc/6547605 that can be
>>>>>> used
>>>>>> >> > as base for the Pull Request.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On Fri, Sep 13, 2013 at 5:53 AM, Douglas Campos <qmx(a)qmx.me>
>>>>>> wrote:
>>>>>> >> > On Thu, Sep 12, 2013 at 09:39:28AM -0300, Bruno Oliveira
>>>>>> >> > wrote:
>>>>>> >> > > Would be nice to have a 8 hands document on it
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > who's going to start the pull request on it? it's
>>>>>> SPECTIME!
>>>>>> >> >
>>>>>> >> > --
>>>>>> >> > qmx
>>>>>> >> > _______________________________________________
>>>>>> >> > aerogear-dev mailing list
>>>>>> >> > aerogear-dev(a)lists.jboss.org
>>>>>> >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > _______________________________________________
>>>>>> >> > aerogear-dev mailing list
>>>>>> >> > aerogear-dev(a)lists.jboss.org
>>>>>> >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> >>
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> aerogear-dev mailing list
>>>>>> >> aerogear-dev(a)lists.jboss.org
>>>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Matthias Wessendorf
>>>>>> >>
>>>>>> >> blog: http://matthiaswessendorf.wordpress.com/
>>>>>> >> sessions: http://www.slideshare.net/mwessendorf
>>>>>> >> twitter: http://twitter.com/mwessendorf
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> aerogear-dev mailing list
>>>>>> >> aerogear-dev(a)lists.jboss.org
>>>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> aerogear-dev mailing list
>>>>>> >> aerogear-dev(a)lists.jboss.org
>>>>>> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > aerogear-dev mailing list
>>>>>> > aerogear-dev(a)lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > aerogear-dev mailing list
>>>>>> > aerogear-dev(a)lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Matthias Wessendorf
>>>>>> >
>>>>>> > blog: http://matthiaswessendorf.wordpress.com/
>>>>>> > sessions: http://www.slideshare.net/mwessendorf
>>>>>> > twitter: http://twitter.com/mwessendorf
>>>>>> > _______________________________________________
>>>>>> > aerogear-dev mailing list
>>>>>> > aerogear-dev(a)lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 5 months
Encrypted Data and IVs
by Summers Pittman
Checking my thoughts (and hopefully spurring some discussion)
A key (and thus salt) is unique per user.
A IV is unique per encrypted message.
In an key pair, the public key is transmitted to your recipients. The
private key is kept by the user.
With a symmetric key, both parties have the key or know how to generate
the key.
The same IV has to be present for a message to be reliably encrypted and
decrypted.
Now some questions:
How is a PBKDF2 key transmitted so a message can be decrypted?
In the case of client server how should the IV be generated/transmitted?
10 years, 5 months
AeroGear Android Crypto / DataManager Proposal
by Daniel Passos
<#> The idea is implementing only save(add/update) and delete, using the
stores we already have today by just adding crypt / decrypt and scheduling
Query (readWithFilter) for the next release
*DataManager*
public Store encryptedStore(String storeName, String passphrase) {
// TODO Create a default passphrase-based KeyStore
KeyStore keyStore = null;
return encryptedStore(storeName, keyStore);
}
public Store encryptedStore(String storeName, KeyStore keyStore) {
StoreConfig storeConfig = new StoreConfig();
storeConfig.setType(StoreTypes.ENCRYPTED_MEMORY);
return encryptedStore(storeName, storeConfig, keyStore);
}
public Store encryptedStore(String storeName, StoreConfig config,
String passphrase) {
// TODO Create a default passphrase-based KeyStore
KeyStore keyStore = null;
return encryptedStore(storeName, config, keyStore);
}
public Store encryptedStore(String storeName, StoreConfig config,
KeyStore keyStore) {
config.setKeyStore(keyStore);
Store store = storeFactory.createStore(config);
stores.put(storeName, store);
return store;
}
*EncryptedMemoryStore*
public class EncryptedMemoryStore<T> implements Store<T> {
private final MemoryStorage<T> memoryStorage;
private final CryptoUtils<T> cryptoUtils;
public EncryptedMemoryStore(IdGenerator idGenerator, KeyStore keyStore) {
memoryStorage = new MemoryStorage(idGenerator);
cryptoUtils = new CryptoUtils<T>(keyStore);
}
@Override
public StoreType getType() {
return StoreTypes.ENCRYPTED_MEMORY;
}
@Override
public Collection<T> readAll() throws InvalidKeyException {
Collection<T> encryptedCollection = memoryStorage.readAll();
return cryptoUtils.decrypt(encryptedCollection);
}
@Override
public T read(Serializable id) throws InvalidKeyException {
T encryptedItem = memoryStorage.read(id);
return cryptoUtils.decrypt(encryptedItem);
}
@Override
public List<T> readWithFilter(ReadFilter filter) throws
InvalidKeyException {
List<T> encryptedList = memoryStorage.readWithFilter(filter);
return cryptoUtils.decrypt(encryptedList);
}
@Override
public void save(T item) {
memoryStorage.save(cryptoUtils.encrypt(item));
}
@Override
public void reset() {
memoryStorage.reset();
}
@Override
public void remove(Serializable id) {
memoryStorage.remove(id);
}
@Override
public boolean isEmpty() {
return memoryStorage.isEmpty();
}
}
*CryptoUtils*
Here is where the magic happens.
public class CryptoUtils<T> {
private final KeyStore keyStore;
public CryptoUtils(KeyStore keyStore) {
this.keyStore = keyStore;
}
public Collection<T> decrypt(Collection<T> encryptedCollection) {
List<T> decryptedList = new ArrayList<T>();
for (T item : encryptedCollection) {
decryptedList.add(decrypt(item));
}
return decryptedList;
}
public List<T> decrypt(List<T> encryptedList) {
List<T> decryptedList = new ArrayList<T>();
for (T item : encryptedList) {
decryptedList.add(decrypt(item));
}
return decryptedList;
}
public T decrypt(T item) {
// TODO Read all fields and decrypt
return item;
}
public T encrypt(T item) {
// TODO Read all fields and encrypt
return item;
}
}
10 years, 5 months
Fwd: packet truncating for wire exchange.
by Lucas Holmquist
Interesting discussion on simplepush happening
Begin forwarded message:
> From: JR Conlin <jrconlin(a)mozilla.com>
> Subject: Re: packet truncating for wire exchange.
> Date: November 5, 2013 3:27:21 PM EST
> To: Doug Turner <doug.turner(a)gmail.com>
> Cc: Jeremiah Orem <oremj(a)mozilla.com>, dev-simplepush(a)mozilla.org
>
> First off, this was merely a proposal, not a demand or request. I simply
> was noting that some efficiency could be introduced with minimal impact.
>
> That said, I can also offer the following helpful points:
>
> TCP structures are not set to a static length. The TCP header specifies
> the "window size" of the data packet.
> http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_st...
>
> TCP window sizes can be between 2 and 65,535 bytes by default or a
> scaling factor may be used (see RFC 1323) which can expand a window size
> up to 1GB. Packets of that size are generally not recommended for most
> systems due to the increasing chance of corruption on non dedicated links.
>
> There are other considerations regarding TCP tuning that can effect
> retransmission or optimization of data packets, but our data is
> generally far, far below that.
>
> Where things become more of a concern is that metering is generally done
> not by packets but by bits. (This is why carriers tend to refer to
> connections using the small "b" indicating a given link can exchange
> 56Kbs or 56,000,000 bits per second). In this case, sending
> {"messageType":"hello"} (using ASCII) would require 24 Bytes of
> information, or 192 bits. Sending {"m":"h"} would require 10 bytes of
> information, or 80 bits. While this is purely an example, it should be
> noted that the following would help show the bandwidth consumption of
> repeated transmission:
>
> long form short form
> 1: 192 1: 80
> 2: 384 2: 160
> 3: 576 3: 320
> 4: 768 4: 400
> 5: 960 5: 480
> 6: 1152 6: 540
>
> So after six of these exchanges, we're seeing 612 bits of savings.
> Enough to send another 7 short form messages.
>
> This implementation could be performed without impacting existing code.
> We're using the same data format for exchange (string encoded JavaScript
> Object Notation). JSON provides a very loose binding for data (in that
> data exchanged may have optional components or definitions). This is
> useful in cases where the actual function to process the data may be
> different depending on a sole value within the data being defined. In
> this case, we are using the value of the key "messageType". These
> values, while descriptive, are a bit like me calling you Douglas Turner
> of Mozilla Incorporated located in Mountain View California in the
> United States of America on planet Earth of the Sol System contained in
> the Orion sub-arm of the the Milky Way Galaxy of the Local Galaxy
> Group... Since no one else in this group is called "Doug", it's a
> viable, non confusing means of noting the individual to whom I wish to
> address. Instead of prepping a good deal of memory and instructions to
> cycle over a string, we can simply tell the program to match the first
> character and move on.
>
> Does this help clarify my thinking?
>
> On 2013/11/5 11:50 AM, Doug Turner wrote:
>> No change without data. We need to understand exactly the bandwidth saving (in terms of tcp packets). Hearing about random reports from people deploying isn’t good enough. Lets get the hard data, analyze, then figure out what we should do.
>>
>>
>>
>> On Nov 5, 2013, at 11:48 AM, JR Conlin <jrconlin(a)mozilla.com> wrote:
>>
>>> True, but that would also mean scrapping SimplePush as it stands
>>> currently, since there's no provision for versions. (How does a client
>>> or server know before data exchange which protocol is being used?)
>>>
>>> So far, we've not experienced any problems with SimplePush, mostly
>>> because it has yet to get wide traction.
>>>
>>> While tossing out the protocol may have minimal impact to ourselves, it
>>> does mean that we've wasted a good deal of time and marketing from both
>>> ourselves and groups like Aerogear. I don't think they'd appreciate us
>>> tossing things, and might not be as welcoming to the next version of
>>> whatever we release.
>>>
>>> (on a somewhat personal note, this is why I tend to advocate for
>>> quieter, internal releases and iterations of projects like this before
>>> we try to seek wide adoption.)
>>>
>>> On 2013/11/5 11:39 AM, Doug Turner wrote:
>>>> If we make any change to the wire protocol, we should start form the beginning and design a binary protocol (not what we have now). We also may want to move away from web sockets.
>>>>
>>>> Has this become any significant problem?
>>>>
>>>>
>>>>
>>>>
>>>> On Nov 5, 2013, at 11:35 AM, Jeremiah Orem <oremj(a)mozilla.com> wrote:
>>>>
>>>>> If we are thinking about changing the format of the messages, I'd like to throw an additional idea in to the ring.
>>>>>
>>>>> Right now, with Go, we have to decode the message to a map instead of a struct, because we don't know the message fields ahead of time. If we changed the structure to {"m":"h", "d": {"u":"123abcd...","c":[...]}}, we could use the RawMessage decoder. for example:
>>>>>
>>>>> type Message struct {
>>>>> MessageType string `json:"m"`
>>>>> Data *json.RawMessage `json:"d"`
>>>>> }
>>>>>
>>>>> type HelloMessage struct {
>>>>> Uaid string `json:"u"`
>>>>> C []string `json:"c"`
>>>>> }
>>>>>
>>>>> var d Message
>>>>> json.Unmarshal(msg, &d)
>>>>> switch d.MessageType {
>>>>> case "h":
>>>>> var h HelloMessage
>>>>> d.Data.UnMarshal(&h)
>>>>> fmt.Println(h.Uaid, h.C)
>>>>> ....
>>>>>
>>>>> Any reason not to do this?
>>>>>
>>>>> -Jeremy
>>>>>
>>>>> JR Conlin wrote:
>>>>>> Looking at the packets being exchanged between server and client, it
>>>>>> strikes me that they're a bit... wordy. That's great for docs and demo
>>>>>> code, not so hot for user bandwidth costs.
>>>>>>
>>>>>> Fortunately, it looks like we can trim things down quite a bit by just
>>>>>> doing lead character checks. For example: the "hello" packet is:
>>>>>>
>>>>>> {"messageType":"hello", "uaid":"123abcd...", "channelIDs":[...]}
>>>>>>
>>>>>> This could be trimmed down to just:
>>>>>> {"m":"h", "u":"123abcd...","c":[...]}
>>>>>>
>>>>>> We could do the same trick with most of the other packets as well. I'm
>>>>>> betting you can probably figure out which these are:
>>>>>>
>>>>>> {"m":"r","u":"234cdef..."}
>>>>>> {"m":"p"}
>>>>>> {"m":"u","u":"234cdef..."}
>>>>>> {"m":"n","u":[{"c":"123abcd...","v":1},{"c":"234cdef...","v":2}]}
>>>>>>
>>>>>> Since the context of the message is already determined by the message
>>>>>> type, and there's only a few message types presented, it's easy to
>>>>>> determine the data.
>>>>>>
>>>>>> Granted, we're not saving a ton per message, but a fair bit in
>>>>>> aggregate. In addition, key matches would obviously be a fair bit
>>>>>> faster, since your only matching single values. Or you could add a
>>>>>> wrapper that detects the short "m" key, and converts things back to
>>>>>> "long form".
>>>>>>
>>>>>> granted, this is somewhat complicated because there's no version. While
>>>>>> not strictly required for this (short keys are a pretty good indicator
>>>>>> of the change being used), it does mean that any future change might be
>>>>>> a bit difficult to do, and limits us to 52 potential message types.
>>>>>>
>>>>>> Thoughts?
>>>>>> _______________________________________________
>>>>>> Dev-simplepush mailing list
>>>>>> Dev-simplepush(a)mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/dev-simplepush
>>>>> _______________________________________________
>>>>> Dev-simplepush mailing list
>>>>> Dev-simplepush(a)mozilla.org
>>>>> https://mail.mozilla.org/listinfo/dev-simplepush
>>>>
>>>
>>
>
> _______________________________________________
> Dev-simplepush mailing list
> Dev-simplepush(a)mozilla.org
> https://mail.mozilla.org/listinfo/dev-simplepush
10 years, 5 months
