On 10/26/2013 04:11 PM, Matthew Toseland wrote: > On 25/10/13 02:05, xor wrote: >> Hi, >> the last remaining TODO of merging the "event-notifications" branch of WOT >> to >> the master branch is to ask you guys for your opinion on whether you are OK >> with the FCP API. This mail does that.
Glad to see it - thank you for writing all this up! >> Short summary of what event-notifications provides: Before >> event-notifications, >> a WOT client would be implemented by periodically polling WOT for identities >> / >> trusts / scores. This caused a lot of database queries and made everything >> slow and laggy. >> With event-notifications, clients of WOT subscribe to types of objects which >> they are interested in: Identities / Trusts / Scores / and in the future >> introduction puzzles. WOT will then send all known objects at time of >> subscripion once, and afterwards keep the client up to date by only sending >> single objects as they are changed (= as an event happens). This causes >> database >> and network traffic only to happen when there is an actual need for it. This seems concerning to me. It is a very odd client application that wants to pull in WoT's entire view of the web of trust. I assume this means the initial state of all things matching a query, and notifications are sent whenever the results change? Having the ability to subscribe to everything or an entire category of things - though very odd - I am okay with, if only because it's convenient for debugging. A condition of "*" or something would be fine. >> I originally wanted to link you to the JavaDoc but we currently do not have >> a >> proper way of auto-generating it on a webserver. For Fred the build scripts update it on release: https://github.com/freenet/scripts/blob/master/release-fred#L199 >> I had a better idea though: The end of this mail will contain a dump of the >> FCP traffic between a client of event-notifications and WOT. So you can have >> a look at how the communication typically looks. >> Before that, there will be a copy-pasta of the JavaDoc of the "Subscribe" >> FCP >> function - this is the initial function which enables event-notifications. >> Its >> JavaDoc will give you a rough idea of how to interpret the following FCP >> dump. >> >> NOTICE: Even though by this mail significant effort is being spent on making >> FCP >> easy to use by client authors, you should only implement an actual FCP >> client >> as a last resort: I've done the job of implementing a Java class >> "FCPClientReferenceImplementation" which serves the purpose of providing a >> reference client to event-notifications. This took around 3 weeks, is ~1000 >> lines and very thoroughly tested. Please use it. Very nice! I think this is an excellent layer of separation to have. Client applications should not always have to deal with parsing text to do WoT things. Maybe this interface could even be cleanly replaced in the future with something more direct where appropriate like OSGi? >> >> FCP "Subscribe" JavaDoc (removed some uninteresting parts): >> ------------------------------------------------------------------------------ >> Processes the "Subscribe" FCP message, filing a {@link Subscription} to >> event-{@link Notification}s via {@link SubscriptionManager}. So far so good. >> Required fields: >> "To" = "Identities" | "Trusts" | "Scores" - chooses among {@link >> IdentitiesSubscription} / {@link TrustsSubscription} / >> {@link ScoresSubscription}. It took me a few minutes to understand that this means that the "To" field can be one of the values "Identities", "Trusts", or "Scores". It'd be helpful if it was clearer somehow. Maybe: To = [Identities|Trusts|Scores] ? Maybe just English. Is my understanding correct that this is an internal WoT function for parsing FCP from clients, and not a part of the reference event notifications client? It's just for understanding the FCP fields in use? >> Reply: >> The reply consists of two separate FCP messages: >> The first message is "Message" = "Identities" | "Trusts" | "Scores". >> It contains the full dataset of the type you have subscribed to. >> By storing this dataset, your client is completely synchronized with WOT. >> Upon >> changes of anything, WOT will only have to send >> the single {@link Identity}/{@link Trust}/{@link Score} object which has >> changed for your client to be fully synchronized again. WoT is synchronizing entire categories of stuff? Always sending everything is insanity. I really think WoT should allow much more selectiveness. The concept of keeping state up to date with an initial synchronization and subsequent notifications is great, but this returning too much information in a way that requires a lot of additional processing to be useful. Requiring such processing invites another wave of duplicate implementations of WoT-wrangling code in clients. Were I writing a client I think I'd be interested in WoT sending me updates on things like "identities with a Sone context that have a score higher than 0 from the perspective of local identity XYZ." >> This message is send via the synchronous FCP-API: You can signal that >> processing it failed by returning an error in the FCP message processor. >> This >> allows your client to be programmed in a transactional style: If part of the >> transaction which >> stores the dataset fails, you can just roll it back and signal the error to >> WOT. It will rollback the subscription then and >> send an "Error" message, indicating that subscribing failed. You must file >> another subscription attempt then. This sounds like it's just for debugging purposes. Is there a way in which failure to apply an incremental change to the state is not a bug? >> The second message is formatted as: >> "Message" = "Subscribed" >> "SubscriptionID" = Random {@link UUID} of the Subscription. >> "To" = Same as the "To" field of your original message. I'm curious why this ID is not in the first message? Why two messages? >> Errors: >> If you are already subscribed to the selected type, you will only receive a >> message: >> "Message" = "Error" >> "Description" = >> "plugins.WebOfTrust.SubscriptionManager$SubscriptionExistsAlreadyException" >> "SubscriptionID" = Same as in the original "Subscribed" message >> "To" = Same as you requested >> "OriginalMessage" = "Subscribe" Would it be appropriate to have an error code so that some error types can be machine-readable? I remember running into difficulties with this sort of thing with my Infocalypse patches. >> {@link Notification}s: >> Further messages will be sent at any time in the future if an {@link >> Identity} / {@link Trust} / {@link Score} >> object has changed. They will contain the version of the object before the >> change and after the change. Is there a reason to contain the before? Is it to relieve the client of having to store all values to see how much the change was? >> These messages are also send with the synchronous FCP API. In opposite to >> the >> initial synchronization message, by replying with failure to the synchronous >> FCP call, you can signal that you want to receive the same notification >> again. This is inconsistent, and it is confusing to me. If there is not an error during transmission what could resending a message achieve? The client already got the message. >> After a typical delay of {@link >> SubscriptionManager#PROCESS_NOTIFICATIONS_DELAY}, it will be re-sent. >> There is a maximal amount of {@link >> SubscriptionManager#DISCONNECT_CLIENT_AFTER_FAILURE_COUNT} failures per FCP- >> Client. >> If you exceed this limit, your subscriptions will be terminated. You will >> receive an "Unsubscribed" message then as long as your client has not >> terminated the FCP connection. See {@link >> #handleUnsubscribe(SimpleFieldSet)}. >> The fact that you can request a notification to be re-sent may also be used >> to >> program your client in a transactional style. >> If the transaction which processes an event-notification fails, you can >> indicate failure to the synchronous FCP sender and >> WOT will then re-send the notification, causing the transaction to be >> retried. The notion of resending enabling transactional state changes seems at odds with being unsubscribed after hitting a limit on them. I'm still not clear on how re-sending could help any kind of error. >> If your client is shutting down or not interested in the subscription >> anymore, >> you should send an "Unsubscribe" message. >> See {@link #handleUnsubscribe(SimpleFieldSet)}. This will make sure that WOT >> stops gathering data for your subscription, >> which would be expensive to do if its not even needed. But if you cannot >> send >> the message anymore due to a dropped connection, >> the subscription will be terminated automatically after some time due to >> notification-deployment failing. Nevertheless, >> please always unsubscribe when possible. Does WoT not have visibility on when FCP connections close? How does WoT handle pushing messages over FCP? I had to jump through hoops to do that with Infocalypse. >> ------------------------------------------------------------------------------ >> >> FCP dump of a typical connection which subscribes to all types of objects:: >> (Notice that the duplicate fields are for backwards compatibility with old >> clients. >> They are present even in event-notifications because the functions for >> generating >> FCP data are re-used in different areas of code.) >> ------------------------------------------------------------------------------ >> ---------------- Fri Oct 25 02:14:07 CEST 2013 Connected. ---------------- >> ---------------- Fri Oct 25 02:14:07 CEST 2013 Sent: ---------------- >> Message=Subscribe >> To=Identities >> End I guess it makes sense that it needs no more information if there are three predetermined things a client can subscribe to. >> ---------------- Fri Oct 25 02:14:08 CEST 2013 Received: ---------------- >> Message=Identities >> Identities.Amount=5 >> Identities.0.CurrentEditionFetchState=NotFetched >> Identities.0.ID=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> Identities.0.Identity=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> Identities.0.PublishesTrustList=true >> Identities.0.RequestURI=USK@QeTBVWTwBldfI- >> lrF~xf0nqFVDdQoSUghT~PvhyJ1NE,OjEywGD063La2H- >> IihD7iYtZm3rC0BP6UTvvwyF5Zh4,AQACAAE/WebOfTrust/1344 >> Identities.0.Type=Identity >> Identities.0.Contexts.Amount=0 >> Identities.0.Properties.Amount=0 >> Identities.1.CurrentEditionFetchState=NotFetched >> Identities.1.ID=D3MrAR-AVMqKJRjXnpKW2guW9z1mw5GZ9BB15mYVkVc >> Identities.1.Identity=D3MrAR-AVMqKJRjXnpKW2guW9z1mw5GZ9BB15mYVkVc >> Identities.1.PublishesTrustList=true >> Identities.1.RequestURI=USK@D3MrAR- >> AVMqKJRjXnpKW2guW9z1mw5GZ9BB15mYVkVc,xgddjFHx2S~5U6PeFkwqO5V~1gZngFLoM- >> xaoMKSBI8,AQACAAE/WebOfTrust/4959 >> Identities.1.Type=Identity >> Identities.1.Contexts.Amount=0 >> Identities.1.Properties.Amount=0 >> Identities.2.CurrentEditionFetchState=NotFetched >> Identities.2.ID=s88mAwLB3OW6mYlZ43XaHDM1K6QXosZ4QTt2UX-hq6s >> Identities.2.Identity=s88mAwLB3OW6mYlZ43XaHDM1K6QXosZ4QTt2UX-hq6s >> Identities.2.PublishesTrustList=true >> Identities.2.RequestURI=USK@s88mAwLB3OW6mYlZ43XaHDM1K6QXosZ4QTt2UX- >> hq6s,555tpw1TUReXUixAMDQD3RcD6gUKwOBCDQ6Dot2v6qg,AQACAAE/WebOfTrust/5 >> Identities.2.Type=Identity >> Identities.2.Contexts.Amount=0 >> Identities.2.Properties.Amount=0 >> Identities.3.CurrentEditionFetchState=NotFetched >> Identities.3.ID=z9dv7wqsxIBCiFLW7VijMGXD9Gl-EXAqBAwzQ4aq26s >> Identities.3.Identity=z9dv7wqsxIBCiFLW7VijMGXD9Gl-EXAqBAwzQ4aq26s >> Identities.3.PublishesTrustList=true >> Identities.3.RequestURI=USK@z9dv7wqsxIBCiFLW7VijMGXD9Gl- >> EXAqBAwzQ4aq26s,4Uvc~Fjw3i9toGeQuBkDARUV5mF7OTKoAhqOA9LpNdo,AQACAAE/WebOfTrust/1270 >> Identities.3.Type=Identity >> Identities.3.Contexts.Amount=0 >> Identities.3.Properties.Amount=0 >> Identities.4.CurrentEditionFetchState=NotFetched >> Identities.4.ID=o2~q8EMoBkCNEgzLUL97hLPdddco9ix1oAnEa~VzZtg >> Identities.4.Identity=o2~q8EMoBkCNEgzLUL97hLPdddco9ix1oAnEa~VzZtg >> Identities.4.PublishesTrustList=true >> Identities.4.RequestURI=USK@o2~q8EMoBkCNEgzLUL97hLPdddco9ix1oAnEa~VzZtg,X~vTpL2LSyKvwQoYBx~eleI2RF6QzYJpzuenfcKDKBM,AQACAAE/WebOfTrust/9379 >> Identities.4.Type=Identity >> Identities.4.Contexts.Amount=0 >> Identities.4.Properties.Amount=0 >> End It seems evident that actual responses will be orders of magnitude larger. Why are both Identity and ID specified as the same thing? I was under the impression is is an identity ID - would just ID be okay? IIRC it's already not going to be backwards-compatible with existing clients due to the full stops between key segments. What are Contexts.Amount and Properties.Amount for? The number of each that are given? I think "Count" might be a clearer name. >> ---------------- Fri Oct 25 02:14:08 CEST 2013 Received: ---------------- >> Message=Subscribed >> SubscriptionID=19b22c4e-b902-4e1a-8dfd-704499ce3fe2 >> To=Identities >> End >> >> ---------------- Fri Oct 25 02:14:08 CEST 2013 Sent: ---------------- >> Message=Subscribe >> To=Trusts >> End >> >> ---------------- Fri Oct 25 02:14:08 CEST 2013 Received: ---------------- >> Message=Trusts >> Trusts.Amount=0 >> End >> >> ---------------- Fri Oct 25 02:14:08 CEST 2013 Received: ---------------- >> Message=Subscribed >> SubscriptionID=c27ef403-2550-41be-bb35-42c5886729f5 >> To=Trusts >> End >> >> ---------------- Fri Oct 25 02:14:08 CEST 2013 Sent: ---------------- >> Message=Subscribe >> To=Scores >> End >> >> ---------------- Fri Oct 25 02:14:08 CEST 2013 Received: ---------------- >> Message=Scores >> Scores.Amount=0 >> End >> >> ---------------- Fri Oct 25 02:14:08 CEST 2013 Received: ---------------- >> Message=Subscribed >> SubscriptionID=031f7f79-3487-455b-9a91-78cec7e72d79 >> To=Scores >> End >> >> ---------------- Fri Oct 25 02:15:20 CEST 2013 Received: ---------------- >> Message=IdentityChangedNotification >> AfterChange.Context0=Introduction I think a key of AfterChange.Context.0 would be preferable for consistent separation of the number. Why isn't there an AfterChange.Context (without the trailing 0) like the other fields? >> AfterChange.CurrentEditionFetchState=Fetched >> AfterChange.CurrentEditionFetchState0=Fetched I'm confused why these and others are duplicated save for a 0 on the end of the key. Where are the meanings of the possible values for fields like this documented? >> AfterChange.ID=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.ID0=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Identity=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Identity0=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.InsertURI=USK@AILRi~9nfD2pesTkeDvwZxe3cRmkY7Q00CUxQyUOVW- >> H,GzEIwcFQ78J7-RCzxgvY4Pfq0T8Lm4v0BazjMtkqT~8,AQECAAE/WebOfTrust/0 >> AfterChange.InsertURI0=USK@AILRi~9nfD2pesTkeDvwZxe3cRmkY7Q00CUxQyUOVW- >> H,GzEIwcFQ78J7-RCzxgvY4Pfq0T8Lm4v0BazjMtkqT~8,AQECAAE/WebOfTrust/0 >> AfterChange.Nickname=Alexandre_Umpleby >> AfterChange.Nickname0=Alexandre_Umpleby >> AfterChange.PublishesTrustList=true >> AfterChange.PublishesTrustList0=true >> AfterChange.RequestURI=USK@WNOyZsnZtpFjwmwfVBqC1PhSeg- >> hErXHlkrR43h0tiU,GzEIwcFQ78J7- >> RCzxgvY4Pfq0T8Lm4v0BazjMtkqT~8,AQACAAE/WebOfTrust/0 >> AfterChange.RequestURI0=USK@WNOyZsnZtpFjwmwfVBqC1PhSeg- >> hErXHlkrR43h0tiU,GzEIwcFQ78J7- >> RCzxgvY4Pfq0T8Lm4v0BazjMtkqT~8,AQACAAE/WebOfTrust/0 >> AfterChange.Type=OwnIdentity >> AfterChange.Type0=OwnIdentity Would this API change be a place to change the name to LocalIdentity? >> AfterChange.Contexts.Amount=1 >> AfterChange.Contexts.0.Name=Introduction >> AfterChange.Contexts0.Amount=1 >> AfterChange.Contexts0.Context0=Introduction I notice - for example - "Contexts" is plural and in the initial sync message "Identity" is singular. It'd make sense to me to make the components consistently one way or another. I have a preference for singular because it's shorter. >> AfterChange.Identities.Amount=1 >> AfterChange.Identities.0.Context0=Introduction >> AfterChange.Identities.0.CurrentEditionFetchState=Fetched >> AfterChange.Identities.0.ID=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Identities.0.Identity=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Identities.0.InsertURI=USK@AILRi~9nfD2pesTkeDvwZxe3cRmkY7Q00CUxQyUOVW- >> H,GzEIwcFQ78J7-RCzxgvY4Pfq0T8Lm4v0BazjMtkqT~8,AQECAAE/WebOfTrust/0 >> AfterChange.Identities.0.Nickname=Alexandre_Umpleby >> AfterChange.Identities.0.PublishesTrustList=true >> AfterChange.Identities.0.RequestURI=USK@WNOyZsnZtpFjwmwfVBqC1PhSeg- >> hErXHlkrR43h0tiU,GzEIwcFQ78J7- >> RCzxgvY4Pfq0T8Lm4v0BazjMtkqT~8,AQACAAE/WebOfTrust/0 >> AfterChange.Identities.0.Type=OwnIdentity >> AfterChange.Identities.0.Contexts.Amount=1 >> AfterChange.Identities.0.Contexts.0.Name=Introduction The ".Name" part seems unnecessary to me. >> AfterChange.Identities.0.Properties.Amount=1 >> AfterChange.Identities.0.Properties.0.Name=IntroductionPuzzleCount >> AfterChange.Identities.0.Properties.0.Value=10 How about AfterChange.Identity.0.Property.IntroductionPuzzleCount=10 ? >> AfterChange.Identities.0.Property0.Name=IntroductionPuzzleCount >> AfterChange.Identities.0.Property0.Value=10 >> AfterChange.Properties.Amount=1 >> AfterChange.Properties.0.Name=IntroductionPuzzleCount >> AfterChange.Properties.0.Value=10 >> AfterChange.Properties0.Amount=1 >> AfterChange.Properties0.Property0.Name=IntroductionPuzzleCount >> AfterChange.Properties0.Property0.Value=10 >> AfterChange.Property0.Name=IntroductionPuzzleCount >> AfterChange.Property0.Value=10 >> BeforeChange.Type=Inexistent >> BeforeChange.Type0=Inexistent >> BeforeChange.Identities.0.Type=Inexistent It looks like "inexistent" is actually a word, but it's not one that I knew. I'd have expected "nonexistent." This may be a place where including the "before" value can lead to odd corner cases, and I wonder if it's worth including. Instead of a word, would it make sense to have an empty string? Why isn't there a BeforeChange for every AfterChange? >> End >> >> ---------------- Fri Oct 25 02:15:21 CEST 2013 Received: ---------------- >> Message=ScoreChangedNotification >> AfterChange.Scores.Amount=1 >> AfterChange.Scores.0.Capacity=100 What does capacity mean here? >> AfterChange.Scores.0.Rank=0 >> AfterChange.Scores.0.Trustee=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Scores.0.Truster=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Scores.0.Value=2147483647 >> BeforeChange.Scores.0.Value=Inexistent >> End >> >> ---------------- Fri Oct 25 02:15:21 CEST 2013 Received: ---------------- >> Message=TrustChangedNotification >> AfterChange.Trusts.Amount=1 >> AfterChange.Trusts.0.Comment=Automatically assigned trust to a seed identity. >> AfterChange.Trusts.0.Trustee=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> AfterChange.Trusts.0.Truster=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Trusts.0.TrusterEdition=0 >> AfterChange.Trusts.0.Value=100 >> BeforeChange.Trusts.0.Value=Inexistent >> End >> >> ---------------- Fri Oct 25 02:15:21 CEST 2013 Received: ---------------- >> Message=TrustChangedNotification >> AfterChange.Trusts.Amount=1 >> AfterChange.Trusts.0.Comment=Automatically assigned trust to a seed identity. >> AfterChange.Trusts.0.Trustee=z9dv7wqsxIBCiFLW7VijMGXD9Gl-EXAqBAwzQ4aq26s >> AfterChange.Trusts.0.Truster=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Trusts.0.TrusterEdition=0 >> AfterChange.Trusts.0.Value=100 >> BeforeChange.Trusts.0.Value=Inexistent >> End >> >> ---------------- Fri Oct 25 02:15:21 CEST 2013 Received: ---------------- >> Message=TrustChangedNotification >> AfterChange.Trusts.Amount=1 >> AfterChange.Trusts.0.Comment=Automatically assigned trust to a seed identity. >> AfterChange.Trusts.0.Trustee=o2~q8EMoBkCNEgzLUL97hLPdddco9ix1oAnEa~VzZtg >> AfterChange.Trusts.0.Truster=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Trusts.0.TrusterEdition=0 >> AfterChange.Trusts.0.Value=100 >> BeforeChange.Trusts.0.Value=Inexistent >> End >> >> ---------------- Fri Oct 25 02:15:21 CEST 2013 Received: ---------------- >> Message=TrustChangedNotification >> AfterChange.Trusts.Amount=1 >> AfterChange.Trusts.0.Comment=Automatically assigned trust to a seed identity. >> AfterChange.Trusts.0.Trustee=D3MrAR-AVMqKJRjXnpKW2guW9z1mw5GZ9BB15mYVkVc >> AfterChange.Trusts.0.Truster=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Trusts.0.TrusterEdition=0 >> AfterChange.Trusts.0.Value=100 >> BeforeChange.Trusts.0.Value=Inexistent >> End >> >> ---------------- Fri Oct 25 02:15:21 CEST 2013 Received: ---------------- >> Message=TrustChangedNotification >> AfterChange.Trusts.Amount=1 >> AfterChange.Trusts.0.Comment=Automatically assigned trust to a seed identity. >> AfterChange.Trusts.0.Trustee=s88mAwLB3OW6mYlZ43XaHDM1K6QXosZ4QTt2UX-hq6s >> AfterChange.Trusts.0.Truster=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Trusts.0.TrusterEdition=0 >> AfterChange.Trusts.0.Value=100 >> BeforeChange.Trusts.0.Value=Inexistent >> End >> >> ---------------- Fri Oct 25 02:15:21 CEST 2013 Received: ---------------- >> Message=ScoreChangedNotification >> AfterChange.Scores.Amount=1 >> AfterChange.Scores.0.Capacity=40 >> AfterChange.Scores.0.Rank=1 >> AfterChange.Scores.0.Trustee=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> AfterChange.Scores.0.Truster=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Scores.0.Value=100 >> BeforeChange.Scores.0.Value=Inexistent >> End >> >> ---------------- Fri Oct 25 02:15:21 CEST 2013 Received: ---------------- >> Message=IdentityChangedNotification >> AfterChange.CurrentEditionFetchState=NotFetched >> AfterChange.CurrentEditionFetchState0=NotFetched >> AfterChange.ID=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> AfterChange.ID0=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> AfterChange.Identity=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> AfterChange.Identity0=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> AfterChange.PublishesTrustList=true >> AfterChange.PublishesTrustList0=true >> AfterChange.RequestURI=USK@QeTBVWTwBldfI- >> lrF~xf0nqFVDdQoSUghT~PvhyJ1NE,OjEywGD063La2H- >> IihD7iYtZm3rC0BP6UTvvwyF5Zh4,AQACAAE/WebOfTrust/1343 >> AfterChange.RequestURI0=USK@QeTBVWTwBldfI- >> lrF~xf0nqFVDdQoSUghT~PvhyJ1NE,OjEywGD063La2H- >> IihD7iYtZm3rC0BP6UTvvwyF5Zh4,AQACAAE/WebOfTrust/1343 >> AfterChange.Type=Identity >> AfterChange.Type0=Identity >> AfterChange.Contexts.Amount=0 >> AfterChange.Contexts0.Amount=0 >> AfterChange.Identities.Amount=1 >> AfterChange.Identities.0.CurrentEditionFetchState=NotFetched >> AfterChange.Identities.0.ID=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> AfterChange.Identities.0.Identity=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> AfterChange.Identities.0.PublishesTrustList=true >> AfterChange.Identities.0.RequestURI=USK@QeTBVWTwBldfI- >> lrF~xf0nqFVDdQoSUghT~PvhyJ1NE,OjEywGD063La2H- >> IihD7iYtZm3rC0BP6UTvvwyF5Zh4,AQACAAE/WebOfTrust/1343 >> AfterChange.Identities.0.Type=Identity >> AfterChange.Identities.0.Contexts.Amount=0 >> AfterChange.Identities.0.Properties.Amount=0 >> AfterChange.Properties.Amount=0 >> AfterChange.Properties0.Amount=0 >> BeforeChange.CurrentEditionFetchState=NotFetched >> BeforeChange.CurrentEditionFetchState0=NotFetched >> BeforeChange.ID=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> BeforeChange.ID0=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> BeforeChange.Identity=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> BeforeChange.Identity0=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> BeforeChange.PublishesTrustList=true >> BeforeChange.PublishesTrustList0=true >> BeforeChange.RequestURI=USK@QeTBVWTwBldfI- >> lrF~xf0nqFVDdQoSUghT~PvhyJ1NE,OjEywGD063La2H- >> IihD7iYtZm3rC0BP6UTvvwyF5Zh4,AQACAAE/WebOfTrust/1344 >> BeforeChange.RequestURI0=USK@QeTBVWTwBldfI- >> lrF~xf0nqFVDdQoSUghT~PvhyJ1NE,OjEywGD063La2H- >> IihD7iYtZm3rC0BP6UTvvwyF5Zh4,AQACAAE/WebOfTrust/1344 >> BeforeChange.Type=Identity >> BeforeChange.Type0=Identity >> BeforeChange.Contexts.Amount=0 >> BeforeChange.Contexts0.Amount=0 >> BeforeChange.Identities.Amount=1 >> BeforeChange.Identities.0.CurrentEditionFetchState=NotFetched >> BeforeChange.Identities.0.ID=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> BeforeChange.Identities.0.Identity=QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE >> BeforeChange.Identities.0.PublishesTrustList=true >> BeforeChange.Identities.0.RequestURI=USK@QeTBVWTwBldfI- >> lrF~xf0nqFVDdQoSUghT~PvhyJ1NE,OjEywGD063La2H- >> IihD7iYtZm3rC0BP6UTvvwyF5Zh4,AQACAAE/WebOfTrust/1344 >> BeforeChange.Identities.0.Type=Identity >> BeforeChange.Identities.0.Contexts.Amount=0 >> BeforeChange.Identities.0.Properties.Amount=0 >> BeforeChange.Properties.Amount=0 >> BeforeChange.Properties0.Amount=0 >> End >> >> ---------------- Fri Oct 25 02:15:21 CEST 2013 Received: ---------------- >> Message=ScoreChangedNotification >> AfterChange.Scores.Amount=1 >> AfterChange.Scores.0.Capacity=40 >> AfterChange.Scores.0.Rank=1 >> AfterChange.Scores.0.Trustee=D3MrAR-AVMqKJRjXnpKW2guW9z1mw5GZ9BB15mYVkVc >> AfterChange.Scores.0.Truster=WNOyZsnZtpFjwmwfVBqC1PhSeg-hErXHlkrR43h0tiU >> AfterChange.Scores.0.Value=100 >> BeforeChange.Scores.0.Value=Inexistent >> End >> >> ---------------- Fri Oct 25 02:43:57 CEST 2013 Sent: ---------------- >> Message=Unsubscribe >> SubscriptionID=19b22c4e-b902-4e1a-8dfd-704499ce3fe2 >> End >> >> ---------------- Fri Oct 25 02:43:57 CEST 2013 Sent: ---------------- >> Message=Unsubscribe >> SubscriptionID=c27ef403-2550-41be-bb35-42c5886729f5 >> End >> >> ---------------- Fri Oct 25 02:43:57 CEST 2013 Sent: ---------------- >> Message=Unsubscribe >> SubscriptionID=031f7f79-3487-455b-9a91-78cec7e72d79 >> End >> >> ---------------- Fri Oct 25 02:43:57 CEST 2013 Received: ---------------- >> From=Identities >> Message=Unsubscribed >> SubscriptionID=19b22c4e-b902-4e1a-8dfd-704499ce3fe2 >> End >> >> ---------------- Fri Oct 25 02:43:57 CEST 2013 Received: ---------------- >> From=Scores >> Message=Unsubscribed >> SubscriptionID=031f7f79-3487-455b-9a91-78cec7e72d79 >> End >> >> ---------------- Fri Oct 25 02:43:57 CEST 2013 Received: ---------------- >> From=Trusts >> Message=Unsubscribed >> SubscriptionID=c27ef403-2550-41be-bb35-42c5886729f5 >> End >> >> ---------------- Fri Oct 25 02:44:00 CEST 2013 Disconnected. >> ---------------- >> ------------------------------------------------------------------------------ >> > The initial state could be huge. Please don't send it as part of the FCP > message's SimpleFieldSet. Either split it up into multiple messages > (e.g. one per identity; but then make sure there is some way of telling > that you got all of them), or (probably better) put it in a Bucket i.e. > a data field. I will go further and say I think it very rarely makes sense for a client application to have to pull in (and keep up-to-date with!) WoT's entire state in the first place. I would expect queries and subscribing to changes in their results.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
